Skip to main content
Every request to the gateway is authenticated with an Orbitrage API key. Keys are workflow-scoped — each key belongs to exactly one project, which is how your calls get attributed without passing anything extra.

​
Key format

The prefix is indexed for fast lookup; the full key is verified against a stored SHA-256 hash. The plaintext is shown once at creation and never stored — if you lose it, revoke and mint a new one.

​
Mint a key

1

Create a project

On the Keys page (or Workflows), create a project. A default key is minted with it.
2

Copy the key

The plaintext appears once. Store it in your secret manager or environment:
3

Use it

Pass it to the SDK (orbitrage.init(key)) or as Authorization: Bearer … on direct HTTP calls.
You can mint additional keys for the same project at any time.

​
List & revoke

  • The Keys page lists active keys with their prefix, last-4, created date, last-used time, and owning project.
  • Revoke is a soft delete — the key stops working immediately, and the row is kept for audit. Any integration using it will start getting 401.
Revocation is visible to the gateway within ~5 minutes (the key-resolution cache TTL). For an immediate cutover, rotate the integration to a new key.

​
How a key maps to your data

You don’t pass an org or workflow id on requests — the key implies both. To attribute calls to your end-users, add the x-orbitrage-end-user-id header (the SDK’s user_id / userId does this). See Observability.

​
Other key types

  • MCP keys (mcp_…) authenticate the MCP server only — a separate namespace from router keys.
  • BYOK provider keys are your own OpenAI/Anthropic/Google/xAI keys, stored encrypted so Orbitrage can forward matching calls to the real provider. They are required for the closed frontier chat models (claude-*, gpt-*, gemini-*, grok-*) and are billed by your provider, not by Orbitrage. See BYOK.