Skip to main content
A key is the identity every request carries. Over its life you create it, maybe pause it during an incident, and eventually retire it. This page walks the whole lifecycle in the console — the fastest way to manage api keys without touching code or redeploying anything. For the full set of constraints a key carries (model allow-lists, IP allow-lists, spend caps, policy attachments), see The token object and Bind policies to a key. This page is about the lifecycle: create → disable → revoke.
All three actions live in the console Keys screen (/console/token). Creating, editing, disabling, or deleting a key requires the Developer role or above; any role (Viewer and up) can read the list.

​
1. Create a key

A new key is born scoped. Rather than minting one broad credential and sharing it, give every agent or service its own key with exactly the limits it needs — that’s what keeps a compromised agent’s blast radius small (see Least-agency checklist). In the console, open Keys → New key and set:
A human-readable name and a free-form environment label (prod, staging, dev, or anything you like) you can later filter logs by. See Environments.
Model allow-list, IP allow-list, a USD spend cap, and an expiry — each optional, each narrowing what the key can do. See Model limits, IP allow-list, and Quota cap & expiry.
A guardrail (guardrail_id) and a firewall policy (firewall_policy_id) to govern this key’s content and tool calls. See Bind policies.
The plaintext key (sk-orca-…) is shown exactly once, at creation. Copy it then. Afterward the console only ever shows a masked form. You can re-reveal an ordinary key’s plaintext later (Developer+), but a gateway-scoped key’s plaintext requires Admin — so save it somewhere safe the first time.
Use the new key for inference exactly as you would any OrcaRouter key: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-4o-mini", "messages": [{"role":"user","content":"ping"}]}'
Only /v1/* relay calls use the sk-orca-… key. The console actions on this page run on your session / access token, not the relay key.

​
2. Disable a key (the reversible pause)

When a key is misbehaving — a runaway loop, a leaked credential you’re still investigating, a service you’re taking offline for maintenance — you don’t have to delete it. Disabling flips the key’s status off so every request it makes is rejected, while the key, its limits, its policy attachments, and its usage history all stay intact. In the Keys list, toggle the key’s status to Disabled. To re-enable it later, toggle it back. A key can be in one of these states:
StatusMeaning
EnabledActive; requests are authorized.
DisabledPaused by you; requests are rejected until re-enabled.
ExpiredPast its expired_time; reached automatically.
ExhaustedHit its quota / spend cap; reached automatically.
Disable is your incident-response pause button. If you suspect a key is compromised but want to keep its config and logs while you dig in, disable first and investigate — then either re-enable or revoke. See Leaked key response.
Expired and Exhausted are reached on their own — a key past its expiry or over its spend cap stops authorizing without any action from you.

​
3. Revoke a key (permanent)

When a key is done — the agent is decommissioned, the credential is confirmed leaked, the project shipped — revoke it by deleting it. This is permanent: the credential can never authorize a request again, and a deleted key is not recoverable. Issue a fresh key for any replacement. In the Keys list, choose Delete on the key (Developer+). To clear out several at once, select them and delete as a batch.
Disable is reversible; delete is not. If there’s any chance you’ll need the key — or its config and history — again, disable it instead. Only delete when you’re certain the credential should cease to exist. For a confirmed leak, deleting immediately cuts off the credential for good; disabling buys you time to investigate first.

​
4. Re-revealing and rotating

A key’s plaintext is masked everywhere in the console after creation. A Developer+ can re-reveal an ordinary key’s plaintext on demand; re-revealing a gateway-scoped key (is_firewall_gateway) requires Admin. Rotation is the safe-handoff pattern: create the replacement key, move your traffic to it, then disable (and later delete) the old one — so there’s never a window with no working key. The full step-by-step lives in Key rotation.

​
5. Who can do what

Every lifecycle action is role-gated against your active workspace:
ActionMinimum role
View the keys listViewer
Create / edit / disable / delete a keyDeveloper
Re-reveal an ordinary key’s plaintextDeveloper
Enable is_firewall_gateway, or read a gateway key’s plaintextAdmin
Workspace scoping means a key created in one workspace is never visible or usable from another. For how keys, policies, and workspaces nest, see Scope & keys.

​
6. Next steps

The token object

Every field a key carries, and what each one constrains.

Bind policies to a key

Attach a guardrail and a firewall policy so the key’s traffic is governed.

Key rotation

The zero-downtime handoff from an old key to a new one.

Leaked key response

What to do the moment you suspect a key is exposed.
The lifecycle is deliberately simple: create narrow, disable to pause, delete to revoke. The narrower each key and the faster you can pause or retire it, the smaller the blast radius when any one agent is compromised.