API key scopes
Restrict a management key to specific capabilities before you hand it out, so a leaked key can only do what it was scoped to do.
Relixr has two kinds of keys. Inference keys just call the gateway (/v1/chat/completions, /v1/embeddings) and never carry management scopes. Management keys act on the dashboard API — reading usage, rotating keys, updating billing — and must be scoped explicitly.
A management key with no scopes is rejected outright: it would authenticate but authorize nothing, which is a confusing credential to hand anyone. Pick at least one scope.
Available scopes
| Scope | Grants |
|---|---|
read:usage | Pull request logs, token counts, and cost data. |
manage:keys | Create, rotate, and revoke inference keys. |
manage:billing | Top up balance and view invoices. |
manage:team | Invite and remove workspace members. |
manage:guardrails | Update content and geo policy rules. |
read:observability | Pull latency and error metrics. |
The rule that keeps this safe
A key can never carry a scope its creator doesn't personally hold. If your workspace role doesn't include billing management, you cannot mint a key with manage:billing on it — not for yourself, and not for a teammate. This applies even to workspace admins delegating to a service account: the delegate's ceiling is the delegator's own permissions, not the platform's maximum.
This matters most for agents and CI credentials: scope those keys to exactly the one or two capabilities the automation needs (usually read:usage or manage:keys alone), never the full set "to be safe." A narrowly scoped key that leaks is a contained incident; a broadly scoped one is not.
Where to set scopes
Scopes are chosen when a management key is created or edited, in the dashboard's key management panel. See Create your first API key for the creation flow, and Agent fleet on Relixr for how this fits into a multi-agent setup.
Still stuck? Help center · Doctor