API keys
Workspace credentials for the MCP server and the ct CLI — one key per agent, read-only when that is all it needs.
API keys are how everything outside the app — the MCP server, the ct CLI, your own scripts — authenticates with your workspace.
Creating a key
In the app, open Settings → API Keys (under Workspace) and create a key. Give it a name, optionally an expiration, and copy it when it’s shown — it is not shown again. Store it somewhere safe, like the secret store your agent already uses. The tab also shows a ready-made Add to Claude Code command for the key.
Read-only keys
Switch on Read-only when creating a key and it can read the workspace but not change
it: every write is refused, whether it comes through MCP, the CLI or a plain HTTP call.
Right for a reporting script, a dashboard, or an agent that should only ever look.
ct status tells you whether the key you are using is read-only.
Using a key
- MCP (hosted): send it as a Bearer token —
Authorization: Bearer <your-api-key> - MCP (local): pass it as the
API_KEYenvironment variable - CLI:
ct logincreates and stores one for you;ct login --api-key <key>stores an existing one
Who did what
A change made with a key is attributed to the member who owns it — the key belongs to you,
and so does what it does. The app adds which agent session made it, so the
timeline and comments read AI · <session> · via <member>, with the
key’s name as the fallback when the client sends no session. That is why one key per
machine or client is enough: several sessions sharing a key stay distinguishable.
Workspace admins see All workspace keys, with each key’s owner, and can delete any of them. Deleting a key cuts that agent’s access at once and disturbs no other.
Rate limits
API traffic is rate limited. Well-behaved agents stay far below the limit; if a runaway
loop hits it, requests are rejected with a standard 429 response and a Retry-After
header until the window resets.