# 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.