Authentication
TokRouter authenticates with sk- API keys; this page covers the two auth header styles, key scope and rotation.
Every request carries an API key. Create it on the console's Tokens page; it looks like
sk-xxxxxxxx.
Auth headers
| Inbound protocol | Header | Example |
|---|---|---|
OpenAI (/v1/chat/completions, /v1/responses, /v1/models) | Authorization | Authorization: Bearer sk-… |
Anthropic (/v1/messages) | x-api-key | x-api-key: sk-… |
Gemini (/v1beta/*) | x-goog-api-key | x-goog-api-key: sk-… |
The gateway accepts either style. Use whatever your SDK sends by default, and do not send both.
Key scope
- One key covers every model and every protocol — no per-vendor keys
- A key can have a quota cap and an expiry; once exceeded or disabled, requests fail authentication
- Usage and billing roll up to the account through the key; create one key per project for isolation
Security practice
Never ship a key to clients
Do not hard-code keys in browsers, mobile apps or desktop clients — anyone who has it can spend your balance. For frontend access, issue short-lived credentials from your backend or proxy the request.
- Inject through environment variables or a secret manager, e.g.
TOKROUTER_API_KEY - Use different keys for development, staging and production
- If a key leaks, delete the token in the console immediately — deletion is instant
- Add a secret scanner to your pre-commit hook to catch
sk-strings
# .env.local (do not commit)
TOKROUTER_API_KEY=sk-xxxxxxxxFailures
| Symptom | Likely cause |
|---|---|
401 | Missing Bearer prefix; key deleted, expired or disabled; password used as key |
403 | The key's group has no access to that model |
429 | Rate limit or quota cap, see Billing |
Response body fields are documented in the API reference.