Create, revoke and rotate API keys

Organize a project around a client purpose

A developer project groups API keys under the signed-in account. Give projects names that explain their use, such as an analytics notebook or a monitoring client, so you can identify the affected integration before revoking a key. Projects are organizational boundaries, not separate subscriptions or request quotas. All projects still use the account's API plan and datasets. Open Developers → API keys and choose the intended project before creating, revoking or deleting anything. Another account's similarly named project does not belong to your current identity.

Save the one-time full key

When creating a key, read the name and project in the reveal dialog, then copy the full om_ key into your intended private storage. The server keeps a hash and cannot show the same secret again later. A prefix helps identify the key but cannot authenticate a request. The dialog's Use this key in the API reference on this device option keeps a browser-tab copy for local reference requests; it is cleared when the tab closes. Turning that option on does not replace saving the credential for your actual client.

Authenticate through headers only

Send the secret through Authorization: Bearer or X-API-Key as documented. Keys placed in URLs are rejected to avoid disclosure through browsing history, shared links and query logging. Do not embed a full key in screenshots, source snippets intended for sharing, support tickets or public assistant configuration. When testing from the reference, inspect the nonsecret request parameters and public prefix without copying the credential into the visible query. If a full key was exposed, plan a replacement and revoke the exposed credential rather than hoping deleting one screenshot recovers its secrecy.

1. Create the key in the intended project and copy its full value once.
2. Configure the client to send it in a supported authentication header.
3. Use its public prefix or a request ID when discussing it with support.

Rotate without confusing two clients

To rotate a key, create a replacement, update the intended client and verify a small authenticated request with the new credential. Then revoke the old key once the client is using the replacement. If the old credential is actively compromised, revoke it promptly and accept that dependent clients will need updating. Name or record the replacement's purpose so later troubleshooting distinguishes it from an unrelated key. A replacement belongs to the same account allowance; rotation does not create a new API rate-limit pool or bypass a subscription restriction.

Revoke the correct key

Choose Revoke beside the intended key and review the name and public prefix in the confirmation dialog. Revocation cannot be undone and subsequent authentication using that key is refused. Existing long-lived streams recheck their authority at the documented boundary, so revocation should not be described as an instantaneous push to every open connection. Confirm the result in the key list and update any remaining client still using the old value. If you lost a key rather than exposed it, create a replacement; the stored hash cannot reconstruct the original.

Delete a project only when it is no longer needed

Project deletion revokes every key in that project. The dialog asks you to type the project name, which helps verify the intended target. Review dependent clients and queued work before confirming, because this is broader than revoking one unused key. The account and unrelated projects remain distinct records, but requests authenticated by the deleted project's keys will be refused. Do not delete and recreate projects as a response to rate limiting: the account still shares 250 requests per rolling minute and a 30-per-second burst limit, with no credits.

Diagnose refused keys safely

Check that the complete key, correct authentication header, project and running base URL are being used. An unknown or revoked key, an inactive project and an unavailable account can all prevent authorization. A recognized key can still receive a subscription or dataset denial. Avoid repeated invalid attempts that can trigger a network cooldown. For support, include the public prefix, project name, route, safe error code and request ID. The full secret, browser cookie and private environment file are unnecessary to identify the failing credential path.