Start hereReference

Authentication

Which headers carry your key, and how keys are stored and revoked.

By the end: You know exactly where your key goes on every route.

Every request carries your key in a header. There are three accepted forms, and which one applies depends on the route.

Field	Value	Notes
Authorization	Bearer YOUR_API_KEY	Works on every route. Use this unless an SDK insists otherwise.
x-api-key	YOUR_API_KEY	Accepted on /v1/messages and /v1/messages/count_tokens, for Anthropic SDKs.
x-goog-api-key	YOUR_API_KEY	Accepted on /v1beta/models/*, for Gemini SDKs.

Keys in query strings are rejected. A key that appears in a URL ends up in logs and browser history, so the gateway will not accept it there.

What is stored

Only a hash of your key is stored. The plaintext exists for the moment it is created and cannot be recovered. If you lose a key, revoke it and create another.

Rotation and revocation

Revoking takes effect on the next request — there is no cache window. Rotating creates a new key and revokes the old one in a single step, so deploy the new value before retiring the old.

What the gateway never forwards

Your Authorization, x-api-key, and x-goog-api-key headers stop at the gateway. Only anthropic-version and anthropic-beta are passed through, and only on the Messages routes.

Account status

A suspended account is refused with 403 even with a valid key. A key belonging to a suspended account behaves the same way, so a working key is not proof that the account is active.