Skip to main content

​
Bearer tokens

Every request to /api/v1/* and to mcp.postbreeze.ai carries an API key in the Authorization header: 
Authorization: Bearer pb_live_<32 random chars>
Tokens are issued from Settings → Developers in the Postbreeze dashboard. Each one is bound to exactly one workspace.

​
Workspace scope

The Postbreeze API enforces that an API key issued for workspace A can never act on workspace B, regardless of what URL you pass:
  • GET /api/v1/workspaces/<B>/posts with workspace A’s key → 403
  • A leaked key can’t escalate to other workspaces you might own
This is intentional: API keys are designed to live in least-privilege contexts (CI runners, scripts, an LLM client) where you want a tight blast radius.

​
Lifecycle

  • Create — POST /workspaces/:id/api-keys (dashboard does this for you). The plaintext is shown once on the create-modal and never again.
  • Rotate — there’s no “rotate in place.” Mint a new key, swap it in your config, then revoke the old one.
  • Revoke — DELETE /workspaces/:id/api-keys/:keyId. Effective immediately; in-flight requests still complete.

​
What a key cannot do

API keys are deliberately narrower than dashboard sessions. They cannot:
  • Create or delete workspaces
  • Manage other API keys (mint, list, revoke) — that’s dashboard-only, so a leaked key can’t propagate
  • Change billing or invite teammates
  • Hit admin or webhook endpoints
If you need any of those, sign in to the dashboard.

​
Storing keys safely

  • Never commit a key to git. Use environment variables, a secrets manager, or your CI’s encrypted secrets store.
  • Don’t paste a key into a shared chat, screenshot, or screencast. If you suspect leakage, revoke immediately.
  • The key’s first 8 chars (the prefix, shown after pb_live_) are the only part visible in the dashboard list — safe to share in support tickets.