Create and protect an API key

Sign in, verify your email if required, and select the organization that will own and pay for API requests. Open API keys and confirm API access is enabled. Browser sign-in grants access to this management screen; an API request itself needs a separate organization key. Review credits and limits before a paid generation.

The API keys page also shows the OpenAI-compatible address ending in /v1, the Anthropic-compatible address, a copyable free model-catalog check and links to the full connection guides. Copy the address for your client's protocol; the example contains a variable name, never your actual secret. A key can be created while the plan's API access is disabled, but it cannot make inference requests until the plan permits them.

Create and save

Select Create, enter a recognizable workload name, choose an expiry and review the displayed default permissions. The current screen offers 30, 60 or 90 days and shows models:read and inference:write; it does not provide a custom-scope editor. Create the key and copy its full value once into a password manager or operating-system credential store. Confirm in the destination that the value was saved before acknowledging the one-time view. The list cannot reveal the full secret later. Never put it in a repository, URL, screenshot, shell history or support message. For CLI-managed clients, CLI key management stores the key through the operating-system credential store.

Set key limits

Open Key limits on a key to narrow its access without changing the organization. Keep a setting inherited to follow organization and plan changes, or turn inheritance off and select allowed models or capabilities. An empty selection denies the category. Concurrency and request-rate limits are positive whole numbers and are enforced atomically by PostgreSQL for the shared key budget, including retries and rotations. Model choices come from the live Graphile catalog. These settings do not expand organization or plan access.

Change permissions

Open Key permissions for the relevant row. An organization owner or administrator can enable or disable model-catalog access (models:read) and inference (inference:write). Save the changes; if saving fails, the dialog keeps your selections. Removed permissions stop working on the next API request. Updating permissions preserves the secret, expiry and key budget and cannot extend the organization's or plan's access.

Verify before a paid call

Use the key to call the free GET /v1/models endpoint from the first API request. Expect HTTP 200 and a data array of canonical model IDs visible to the key. A display name is not a request ID. If you get 401, re-check the Bearer header, key state and expiry. If you get 403 or an unexpected empty catalog, check the organization and permissions before attempting inference.

Only after that free check should you send the first bounded Responses request. It may consume credits. Save its public request ID, then check the operation in API Activity. The free model-catalog check is not a billed generation and should not be mistaken for an Activity row.

Replace or revoke

The list shows the name, masked prefix, active state, permissions, creation time, last use when known and expiry. If the raw value is lost, create a new key; the old value cannot be recovered from metadata. Test the replacement with the free model catalog, update each client that used the old key, then revoke it. The current browser screen does not rotate a key in place; replacement and revocation are separate confirmed actions. If exposure is suspected, revoke the affected key promptly and use a new value; account security explains the other sessions and grants to review.

Revocation stops the selected API key. It does not log out a browser or revoke a CLI OAuth authorization. Confirm the old key is inactive in the list and that the intended client works with its replacement. For failures, use authentication and errors and limits; keep only a public request ID and safe error code for support.