API keys

Create a key, send it with a request, and reach your organization from your own code instead of the dashboard.

An API key is a single credential with two uses:

• The REST API — every route the dashboard itself calls, reached with the X-API-Key header.
• The MCP server — the tool surface an LLM agent connects to, which accepts the same X-API-Key header or Authorization: Bearer <key>.

One key covers both. There is no separate login step and no token exchange.

Creating a key

Give the key a name on the API keys page and it is generated immediately. The key value is shown to you once, at that moment, and is never shown again — only its first few characters appear in the list afterwards.

Store it in a secret manager as soon as you have it. If you lose the value, archive the key and create a replacement; there is no recovery path.

Name each key for where it will live — the server, the script, the agent that holds it. A key you cannot trace back to its holder is a key you cannot safely archive.

Archiving and reactivating

Archiving is how a key is withdrawn. An archived key stops authenticating immediately, and the list hides archived keys until you ask to see them.

Archiving is reversible. A key you archived can be reactivated later and resumes working with the same value — useful when you pull a key during an incident and want it back afterwards, and a reason to treat archiving as a decision rather than a cleanup habit.

What a key can reach

A key resolves to the user who created it, scoped to the organization it was created in. It carries that user's access — not a subset of it.

There is no permission model on keys. You cannot restrict a key to a set of routes, a set of resources, or a read-only role, and a key does not expire on its own. Anything the creating user can do through the dashboard, a holder of the key can do through the API — including starting a call on a workflow.

The one boundary that does hold is the organization: a key cannot reach another organization's data, whatever the creating user's other memberships are.

Key hygiene

• Issue one key per holder, never a shared key across several services.
• Archive a key the moment its holder is retired, rather than leaving it active indefinitely.
• Rotate by creating the replacement first, moving the holder onto it, then archiving the old key — the two coexist, so there is no gap.

Why this matters

A key has no expiry and no scope, so nothing else limits its blast radius. Naming and rotation are the only controls you have, which makes them worth the discipline rather than optional tidiness.