Skip to main content
When you create or read an API key through the console or the REST API, the gateway returns a token object — the JSON record that holds a key’s identity, its limits, and the two policy attachments that govern its traffic. This page is the field-by-field reference for that object: what each field means, its type, and the sentinel values (0, -1) that carry special meaning. For the why behind these fields — the least-agency model — start at Scoped keys overview. This page is the lookup table you keep open while you script key creation.

1. The token object reference at a glance

A freshly created key for a scheduled summarizer agent looks like this:
{
  "id": 4812,
  "name": "support-summarizer-prod",
  "status": 1,
  "key": "sk-orca-a1b2****yz90",
  "created_time": 1733616000,
  "accessed_time": 1733702400,
  "expired_time": -1,
  "unlimited_quota": false,
  "remain_quota": 500000,
  "used_quota": 12340,
  "model_limits_enabled": true,
  "model_limits": "openai/gpt-4o-mini",
  "credit_limit_usd": 25,
  "allow_ips": "203.0.113.7",
  "environment": "prod",
  "guardrail_id": 17,
  "firewall_policy_id": 9,
  "is_firewall_gateway": false,
  "group": "default"
}
The key field is masked on every read — you see the brand prefix and the last four characters, never the full secret. Plaintext is shown once, at creation. See Key masking.

2. Identity & lifecycle fields

These describe which key this is and where it is in its lifecycle.
The key’s stable numeric identifier. Use it to address the key in update and delete calls. Read-only.
A human label for the key, shown in the console and in logs. Name keys after the agent that holds them — one key, one agent.
Enabled / disabled state. 1 means active; a disabled key is rejected at auth without being deleted, so you can pause a key and re-enable it.
The bearer secret, returned masked (sk-orca-…****…). The full value is shown only once, at creation. Treat it like a password.
Unix timestamps (seconds) for when the key was minted and when it last served a request. accessed_time is your signal for a stale or unused key worth revoking.
Absolute expiry as a Unix timestamp. The sentinel -1 means the key never expires. Set a real timestamp to make a key auto-expire — the right default for CI runs and ephemeral agents. See Expiring keys.

3. Spend & quota fields

These bound how much a key can consume before it stops working.
FieldTypeMeaning
credit_limit_usdnumberLifetime spend cap in USD. 0 = unlimited.
unlimited_quotabooleanWhen true, the key is not metered against a quota balance.
remain_quotanumberQuota remaining on the key.
used_quotanumberQuota consumed so far.
A key with credit_limit_usd: 0 and unlimited_quota: true and expired_time: -1 has no spend ceiling and never expires — the worst blast radius if it leaks. See unlimited vs bounded for when an unbounded key is justified.

4. Reach & scope fields

These cap what the key can reach — which models, from which addresses.
model_limits is the list of models the key may call; model_limits_enabled is the on/off switch. With the limit enabled, a call to any model outside the list is rejected before it leaves the gateway — the agent can’t switch to a pricier or more capable model. See Model limits.
An IP / CIDR allow-list, one entry per line. A request presenting the key from any unlisted address is rejected at the auth layer; an empty value means all addresses are allowed. See IP allow-list.
A free-form deployment label (prod, staging, dev, or anything you choose) for organizing keys and filtering logs. Purely organizational — it doesn’t change enforcement. See Environments.
The routing group the key resolves models through. Leave it at the workspace default unless you’ve been given a specific group.

5. Policy attachment fields

The two most powerful fields on a key. Each binds the key to a workspace-scoped policy that governs its traffic — change the policy and every key attached to it picks up the change on the next request, no redeploy.
FieldTypeBinds the key to
guardrail_idnumberA content guardrail that screens request and response text.
firewall_policy_idnumberA firewall policy that governs the tool calls the key issues.
is_firewall_gatewaybooleanMarks the key as a gateway-scoped token for the Firewall MCP / evaluate routes (not for inference).
The sentinel for both attachments is 0 (unattached). But the two planes resolve a disabled attachment differently:
  • A disabled guardrail_id is the off switch — the key gets no guardrail, with no fallback to the workspace default.
  • A disabled firewall_policy_id falls back to the workspace default firewall policy.
The full resolution order lives on Bind policies and Scope & keys.
is_firewall_gateway: true mints a gateway-scoped key for the /api/v1/firewall/* routes only — never put it on an inference key. Enabling the flag, and reading a gateway key’s plaintext, both require Admin+.

6. Setting these fields

Every field above is configured in the console key editor (/console/token) — not through a relay key. Creating or editing a key requires the Developer role or above; the is_firewall_gateway flag requires Admin+.
The token object is the configuration surface. The key’s plaintext (sk-orca-…) is what your agent presents on /v1/* relay calls. Configure the key in the console; the agent only ever sees the secret.
A concrete least-agency key — set in the editor, read back as the object above — caps one model, one source IP range, a weekly USD ceiling, an expiry, and one guardrail plus one firewall policy. If the agent holding it is hijacked via prompt injection, the blast radius stops at exactly those bounds.

Scoped keys overview

The least-agency model and the hub for every key field.

Bind policies

How guardrail_id and firewall_policy_id resolve to an active policy.

Quota, cap & expiry

credit_limit_usd, expired_time, and the quota fields in depth.

Least-agency checklist

Run every key through the same hardening pass.
New to the model? Read Scope, keys, policies & workspaces for how the token object fits the workspace → policy → key hierarchy.