Get started
Authentication
Every request to the API carries a secret API key that identifies one agent, automation, or server. Anything holding it can act within that key's permissions, so keep it secret. Keys look like sk_live_….
Get a key
- In your dashboard, open your account menu (top right) and click API Keys.
- Name it after the agent or integration it belongs to (e.g.
Football Publisher,CI server) so its activity and authority stay clear. Click Create API key. - Copy the key now: it's shown only once, including from the dashboard SPA. PostLake stores just a scrambled version, so it can never show it to you again. Lost it? Make a new one and delete the old.
Use it on a request
Send the key in a request header called Authorization, in the form Bearer YOUR_KEY. A "header" is just an extra line of info attached to the request; Bearer is the standard word that means "the bearer of this token is allowed in". With curl, the -H flag adds that header:
curl https://api.postlake.dev/v1/me \
-H "Authorization: Bearer sk_live_YOUR_KEY"Every endpoint expects this same header. Leave it off (or mistype the key) and you get a 401 Unauthorized back. The /v1/me call above is the quickest way to check a key is valid. It just echoes your account.
Revoking a key
On the same API Keys page, click Revoke next to any key. It stops working immediately. Do this the moment a key might have leaked (committed to a public repo, pasted in a chat). Because you can name and revoke keys one at a time, a leak of one key never forces you to rotate the others.
Control what a key may publish
Every API key appears in Agent Control as its own machine identity. You can restrict it to selected profiles and networks, set a daily publishing cap, require human approval, and decide whether it may spend purchased credits. PostLake enforces these controls at the API boundary. Existing keys keep their previous publishing access until you add restrictions, so upgrading does not interrupt a working integration.
Keys are server-side only
PostLake keys are secret server-side keys (prefix sk_live_). There's no separate "publishable" key. Every endpoint is server-to-server, so never embed a key in a browser, mobile app, or public repo.