Why key management is dashboard-only
An API key can authenticate search, upload, and collection requests, but it can never create, list, or revoke another key, including its own. Key creation and revocation require a web session token (the one your browser holds after you sign in), specifically so a leaked API key can’t be used to mint new keys or revoke the legitimate ones on the account. There’s no way around this from server-to-server code; if you need a new key, someone has to generate it from the dashboard.What happens when you create a key
key field contains the secret used in the Authorization header. It is only returned in this response. Store it immediately; there’s no way to retrieve it again. If you lose it, revoke the key and create a new one.
Permission levels
Use
read_only keys for trusted agent or server integrations that do not need write access. Do not expose an API key in browser code or other untrusted clients. See MCP overview.
Listing and revoking
Listing returns every key on the account, including revoked ones: the plain secret is never included, onlyprefix (the first 12 characters), so you can tell which key is which. Revocation is immediate and permanent; a revoked key can’t be reactivated.
Plan limits
Creating a key beyond your plan’s limit returns
402 with code API_KEY_LIMIT_REACHED. See Errors.
API key object
Security guidance
- Store keys in environment variables or a secrets manager.
- Do not place keys in client-side code, prompts, logs, or source control.
- Use a separate key for each integration so you can revoke access independently.
- Key creation and revocation require an authenticated dashboard session with the appropriate role.