Getting started
API Keys
Create, restrict, rotate and revoke project API keys.
API keys authenticate requests to the public API. Each key belongs to one project and carries its own scopes and optional restrictions, so you can give every service exactly the access and spending headroom it needs.
Creating a key
- Open API Keys in the console for the project the key should bill to.
- Choose a name, scopes and any restrictions described below.
- Copy the key when it is displayed. It is shown exactly once; afterwards only its prefix (for example
proj_live_AbCd1234) is visible.
Keys are created from the console only; there is no API endpoint that issues keys. See Authentication for how to send a key and how it is stored.
Key settings
| Setting | Type | Description |
|---|---|---|
| name | string | A label for the key, 1–64 characters. |
| scopes | string[] | At least one of inference agents sandboxes receipts. The agents scope is reserved for the upcoming agents API Coming soon |
| allowed models | string[] | null | Up to 64 model IDs. Empty means the key adds no model restriction beyond the project policy. |
| monthly limit | USD | null | Maximum committed spend for this key per UTC calendar month. Empty means no key-level limit. |
| requests per minute | integer | null | 1–10,000. Empty means the default of 60 requests per minute. |
| expiration | timestamp | null | Optional. Must be in the future when the key is created. |
Restrictions
Restrictions are enforced by the gateway on every request, before any reservation is made or any model is called. A request that violates a restriction is not billed and produces no receipt.
Allowed models
Model allowlists exist at two levels. The project policy defines which models the project may use; a key's list can only narrow that set further. A model must pass both checks, otherwise the request fails with model_not_allowed (HTTP 403) and param: "model".
Monthly limit
The limit is compared with the key's committed spend for the current UTC calendar month: the settled cost of completed inference requests and sandbox executions, plus reservations for operations still in flight. A new request is rejected with budget_exceeded (HTTP 402) if its reservation would push committed spend over the limit. Because the reservation is an upper bound, lowering max_completion_tokens lets requests close to the limit through. See Budgets.
Rate limit
Each key has a fixed one-minute window counter. When the count exceeds the key's limit, requests fail with rate_limit_exceeded (HTTP 429) and a retry-after header giving the seconds until the window resets. The project policy has its own requests-per-minute limit that applies across all keys. Rate limits apply to inference and sandbox executions; see Usage.
Expiration
Once the expiration time passes, the key is rejected with invalid_api_key (HTTP 401), exactly as if it had been revoked. Expiration cannot be extended; create a new key instead.
Revoking a key
Revoke a key from the console. Revocation is permanent and takes effect on the next request that uses the key. Requests already executing complete and are billed normally. Revoked keys remain listed with their revocation time for auditing.
Rotating keys
Keys cannot be regenerated in place. To rotate without downtime:
- Create a new key with the same scopes and restrictions.
- Deploy the new key to the service that uses it.
- Confirm in the console that the old key's last used time has stopped advancing.
- Revoke the old key.
Audit trail
Creating and revoking keys writes audit log entries (api_key.created with the prefix and scopes, api_key.revoked with the prefix). The key's hash never leaves the server, and the key itself is never logged.