Manage Compute API keys

Give each independently managed client its own key. You choose the client, scope and expiry; keep the secret private and verify changes in the intended account. If you do not have approved access, Apply for Compute API access; the application asks for review and does not grant access, issue a key, start work or charge you.

Store and review the assigned key

With approved Compute access and the account's key-management permission, open Access → API keys, then check the account.

Match the key's name and visible prefix to your client's protected credential record. Check Permissions, Created, Expires and whether the key is active, expired or revoked. The prefix identifies a key, but it cannot authenticate a request.

Record the person or service using the key separately from the account owner. A key label does not create a service identity, project boundary or independent budget. You can revoke a shared key, but every client using it then loses that access.

Use the offered creation flow

Use Get my API key only when it is offered, and review its supported choices before creating anything. If the creation action is absent, ask the account administrator to resolve access rather than invoking a different endpoint.

The form starts with quote or read-only permissions when your account offers them. Job and batch submission permissions need an explicit selection from the offered choices. Buying credit or connecting a work tool does not add key permissions.

1. Enter a Name for the client, then choose the offered use case and environment. An environment label does not isolate accounts.
2. Review Permissions and select only the scopes the client needs from the offered choices.
3. Choose Expiry. The preset choices are 1 hour, 24 hours, 7 days, 30 days, 90 days and 1 year; use only those your account offers.
4. Check Review, then select Create key. In Save your key now, capture the secret directly into your approved secret manager and select Done.

Use Reveal key only in a private setup session. Keep the secret out of the clipboard, AI prompts, terminal commands, tickets, repositories and screenshots. Confirm that the intended client loads it from the protected store.

The new secret is returned once. An already-completed creation request can return the key summary without its secret. If the client cannot load the original secret after completion is confirmed, review the key list and arrange an authorized replacement.

If the form reports an unknown creation outcome, keep the page open in the same account and use Retry same request. The form preserves the original request identity and details. Wait for its confirmed outcome before starting a replacement request; if it remains unresolved, ask the account administrator to investigate.

Replace or revoke deliberately

For a routine replacement, create an authorized successor through the offered flow. Update only the intended client and verify a permitted read, then retire the old key. This manager has no separate Rotate action.

Select Revoke on the exact key. Check the name in the confirmation and choose Confirm revoke. Cancel closes the confirmation without revoking. After Key revoked., refresh the page and verify the revoked status.

Verify that the retired credential is rejected through your client's protected credential mechanism. Do not print it during that check. If revocation fails or you cannot read its result, leave the outcome unresolved and ask the administrator to investigate.

Respond to suspected exposure

Stop the affected automation and request revocation immediately. Do not keep an exposed key active just to avoid an interruption. After containing the exposure, arrange a bounded replacement.

Revoking a key does not prove that an accepted job stopped or that downloaded results were erased; review those separately. For support, retain the safe prefix, requested action and error description, never credentials or signed access URLs.