Authenticate API requests
Use an organization key with the correct protocol header and keep it out of logs and URLs.
Use an organization key with the correct protocol header and keep it out of logs and URLs.
Set BASE_URL to your HTTPS API origin without a trailing slash or /v1, and pass API_KEY from your credential store. OpenAI-compatible SDKs use ${BASE_URL}/v1; Anthropic-compatible SDKs use BASE_URL.
Create an organization API key in API keys, save its full value when it is shown once, and verify that the selected organization has API access. The key needs permission for the requested operation. A browser session and CLI OAuth authorization are separate from the API key and cannot be substituted for it on an inference call. Keep the secret in a credential store or secret manager; supply it only to the process making the request.
OpenAI-compatible clients use base URL ${BASE_URL}/v1 and a Bearer token. Anthropic-compatible clients use base URL BASE_URL and the x-api-key header with anthropic-version. Set API_KEY for the process from your secret store before running the examples. Avoid typing the raw value into a shell command: it can enter shell history.
printf 'Authorization: Bearer %s\n' "$API_KEY" \
| curl -q -H @- -i "$BASE_URL/v1/models"
printf 'x-api-key: %s\n' "$API_KEY" \
| curl -q -H @- -i "$BASE_URL/v1/models" \
-H "anthropic-version: 2023-06-01"
Both requests should return HTTP 200 and a data catalog scoped to the key. Model IDs in that catalog are the values to send in generation requests. A 401 means the header or key is missing, invalid or expired; check that the process received the value without printing it. A 403 means its organization or permission cannot use this operation. Verify the selected organization and key metadata before a paid call; errors and limits explains the public codes.
| Operation | Required permission | Check without generation |
|---|---|---|
GET /v1/models, GET /v1/models/{model} | models:read | The catalog request above. |
| Responses, Chat Completions, Messages, and stored conversation operations | inference:write | Inspect key permissions in API keys; generation may debit credits. |
The same key can work with either protocol family when its permissions and organization allow the operation. Give each application or environment its own key instead of sharing one across a team; rotation and investigation become clearer. If a process only needs catalog access, do not grant generation permission for convenience.
Do not place the key in a URL, checked-in config, browser query string, screenshot or support ticket. Do not write full request headers to application logs. If a key is exposed, revoke it in API keys, create a replacement and update each client that used it. Revocation of the key does not end your browser session or CLI grant. See account security for those separate actions.
For a planned rotation, create the new key, verify the free catalog and one allowed call from the new process, switch clients, then revoke the old key. If the old key is already exposed, revoke it immediately and reconnect with a replacement. Its full value cannot be recovered after the one-time display.
Next: select a model, then make a bounded first request.