Concepts
Authentication and API keys
How SubToAPI application keys work: the Authorization header, creating, rotating and revoking sub_live keys, and how to keep them safe.
Updated
Every public endpoint requires a SubToAPI application key sent as a Bearer token. Keys belong to your team, are created in the dashboard and are stored only as SHA-256 hashes — if you lose one, rotate it.
header
Key lifecycle
- Create — Integrate → API keys → *New key*. The full key is shown once.
- Rotate — creates a new key with the same name and revokes the old one in a single step. Update your environment, then nothing else changes.
- Revoke — immediately rejected with
401 invalid_api_key. Usage history stays attached to the key for reporting. - Last used — the dashboard shows when each key last authenticated, so unused keys are easy to spot and remove.
How many keys, how many requests
Active keys and requests per minute depend on your plan. Rate limits are enforced per key and per endpoint in a fixed one-minute window.
Per plan
Keeping keys safe
- Keep keys in environment variables or a secrets manager — never in source code, client bundles or mobile apps.
- Use one key per application or environment so you can revoke one without touching the others.
- Call the API from your backend. If you must call from a browser, restrict the allowed origins in your deployment and proxy through your own server.
- Treat
request_idvalues as safe to log; treat keys as secrets.
A key is a credential for your whole team's Claude access. Anyone holding it can spend your rate limit. Rotate immediately if it leaks.
Frequently asked questions
- Can I see a key again after creating it?
- No — only the prefix is stored. Rotate the key to get a new secret.
- What happens on a wrong key?
- The API answers
401 invalid_api_keywith a JSON body; the message is identical for unknown, malformed and revoked keys.