Keys and authentication

Authorize model calls and restrict each application's access.

Request header#

Use Authorization: Bearer YOUR_API_KEY for model requests. Include one space after Bearer; do not add quotes or line breaks to the key itself.

Model API keys in key management serve a different purpose from personal access tokens on the account security page. Use a model API key for a model client, not an administrative credential.

Groups and model scope#

A key's group determines available channels and applicable prices. A catalog model may still be unavailable to a key because of its group, model restrictions, quota or expiry.

Create a separate key for each application. Set quota, expiry and IP restrictions as needed. Test a small request after changing the model or group.

Storage and rotation#

• Store keys in server environment variables or a secrets manager.
• Keep them out of frontend code, public repositories, shared screenshots and chat logs.
• When rotating, create a new key, update the app, test, then disable the old key.
• If a key may be exposed, disable it immediately and inspect usage and charges.

Authentication errors#

For 401, check the key and headers. For 403, check permissions, source IP and access policies. Inspect the returned message because errors may originate from either the platform or the upstream provider.

CORS determines whether a browser can make a request; it does not protect an embedded key. For a public web application, call the model through your own backend.