What a token is
A credential that lets something other than a browser act on your organisation - a script, a scheduled job, or an MCP client so an AI assistant can use the product with the same permissions and the same audit trail as a person.
The panel's API tokens tab lists the tokens that exist, showing each one's name, prefix, scopes, environment, status, last use and expiry. The prefix is a short non-secret fragment - enough to tell two tokens apart in a log without the log containing a credential.
What scopes mean
A scope is a permission of the form resource:action, and one never implies
another: holding domains:read gives you no ability to write. A token is also
limited by the plan - it can never do something the plan does not sell.
Dangerous scopes are kept out of the ordinary presets and need a stronger check. Anything that could change DNS is the clearest example, and it is deliberately excluded from the developer preset.
Handling one safely
- A token is shown once, when it is created, and never again. Store it in a secret manager, not in a repository, a chat message or a configuration file you commit.
- Give each integration its own token, so one can be revoked without breaking the others.
- Ask for the narrowest scopes that do the job - a read-only integration should hold read-only scopes.
- Revoke anything unused. The last-used column is what tells you which those are.
What is not built yet
Minting a token from the panel is not built
The tab lists tokens and will say so when there are none. Creating one is not there yet: a token is shown once and never again, so it needs a flow that treats that properly rather than a button bolted on to a table.
The public API and the MCP server are on the roadmap. Until they ship there is nothing for a token to be used against.