Skip to content
docs/authenticationGetting Started

Authentication

One key, sent as a bearer token on every request that spends money.

The API key is the credential. There is no session, no cookie and no token exchange: send the key in the Authorization header and the request is authenticated. Keys belong to an account, not to a route. There are no per-endpoint scopes to grant.

The header

cURLcURL
curl https://api.routehook.ai/v1/chat/completions   -H "Authorization: Bearer $ROUTEHOOK_API_KEY"   -H "Content-Type: application/json"   -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{ "role": "user", "content": "Hello" }]
  }'

x-api-key, for Anthropic clients

Every /v1 route also accepts the key in an x-api-key header, not just POST /v1/messages. That is the header an Anthropic SDK sends, and refusing it on the routes next door would buy nothing but support tickets. It is the same key and the same account; nothing else about the request changes. A bare Authorization header carrying the key with no Bearer prefix is accepted too, because that is what a curl example produces when someone drops the word. Authorization: Bearer is the spelling to write against; the other two exist so a request that was obviously meant to work does.

One kind of key

Every key carries the sk_live_ prefix and spends the account's balance. There is no test or sandbox key: a call made while you are trying something out costs exactly what the same call costs in production, because it is the same call. Isolate risk with separate keys instead. Issue one per service, give it a spend cap, and revoke it on its own. GET /v1/key reports the cap as limit and what is left as limit_remaining.

GET/v1/keyAvailable

Describe the key making the call: its label, spend cap, lifetime usage and rate limit.

AUTHENTICATION
Bearer token, Authorization header
REQUIRED SCOPE
api-key

Routes that need no key

The catalogue is public. GET /v1/models, GET /v1/catalog and GET /v1/status answer anonymously and are cached, so a pricing page or a model picker can read them from a browser. Everything that spends money needs a key.

Rotation

Create the replacement key first, deploy it, then revoke the old one. Revocation takes effect immediately, so doing it in the other order takes the integration down for the length of a deploy.

Practices worth keeping

  • One key per project, so revoking one never takes down another.
  • Keep keys in environment variables or a secret manager, never in the repository.
  • Log the key id from GET /v1/key, never the key itself.
  • Rotate on any suspicion. Rotation is cheap, forensics is not.

Authentication failures

STATUSCODEMEANING
401invalid_api_keyKey missing, malformed or revoked
402insufficient_creditsThe key is valid; the balance is not