Create and protect API keys

Scopes and roles

API Keys lists supported scope descriptions, including account read, AI inference and training, AI hosting jobs, model transformation jobs, blockchain services and support-ticket permissions. In an organisation, owners and administrators manage keys; members can view but not manage them. Select the context where the credential should belong, because visibility and authority are context-scoped.

1. Select the intended organisation before opening API Keys.
2. Read scope descriptions and select only required operations.
3. Ask an owner or administrator if management is unavailable.

Create a live key

A standard key needs a 2–120 character name, at least one listed scope and optional IP allowlist. Enter valid IP addresses or CIDR networks, one per line, within the displayed limit. An empty list permits any source IP. The full plaintext appears once after creation; only a hash is stored, so it cannot later be retrieved.

1. Use a name for the application or environment.
2. Choose minimum scopes and necessary stable source addresses.
3. Save the revealed value directly into approved secret storage.

Sandbox inference key

The dashboard can create a sandbox key limited to AI inference and the monthly request allowance shown there. Only one active sandbox key is permitted per account or organisation context. If one exists, use it or revoke it before replacement. Keep sandbox and live credentials separate and do not use a sandbox allowance as a production service guarantee.

1. Check for an active sandbox key in this context.
2. Create one for inference testing and store it separately.
3. Monitor its allowance and revoke it when no longer needed.

Protect the secret

Copy the complete key only when creation or rotation displays it. Store it in an encrypted secret manager with access limited to the consuming service. Never place it in source code, browser code, logs, screenshots, tickets or chat. If you missed the one-time display or cannot locate the value, rotate the key; support cannot retrieve the plaintext.

1. Transfer the revealed value directly to protected storage.
2. Configure the consumer using its documented settings.
3. Rotate immediately if exposure or loss is suspected.

Rotate or revoke

Rotation revokes the old credential and creates a replacement with the same name, tier, scopes and allowlist. The new value is shown once; update dependent services promptly because the old key stops working. Revocation disables the selected key without replacing it. Confirm the correct key and context before submitting either action.

1. Identify every consumer before routine rotation.
2. Store the new value and update dependent services.
3. Revoke retired keys and verify their dashboard state.

Diagnose rejected requests

A request may be rejected if its key is malformed or revoked, its user inactive, source IP outside the allowlist or requested scope absent. Sandbox requests can also exceed their monthly limit. Check context, deployed secret version, caller egress address and required scope. Never provide the secret when asking for assistance.

1. Confirm the key is active and includes the operation scope.
2. Compare actual source IP and sandbox allowance.
3. Rotate if wrong or exposed; share only redacted references.

Frequently asked questions

Related pages

• Understand pricing before you order
• Place and track customer orders
• View subscriptions and billing
• Configure customer webhooks
• Manage organisation membership
• Manage notifications
• Manage profile, security and privacy