API Keys and Spend Limits

Members call the marketplace with API keys that belong to the organization (and, in a team, to the active workspace). Keys, programmatic provisioning, and spend limits all live under API Keys in the Buy section, with each surface gated by role.

Buyer keys

Create and manage the keys used to make inference requests. Each key can carry:

• a scope that constrains which models, providers, or endpoints it may use, along with a provider-trust preference and an optional minimum discount (min_discount_pct, 0-100), and
• an optional spend budget that caps how much it can spend.

Managing keys requires the key-management permission (owner, admin, or developer).

Provisioning keys programmatically

An admin key (inf_admin_...) can mint, scope, rotate, and revoke keys through the /v1/keys API, scoped to its own workspace. Every write on that API requires an Idempotency-Key header. An admin key holds the full capability vocabulary (key management, offers, usage and request-log reads, budgets, webhooks, and the rest), but it still cannot run inference (its key type is rejected at the inference guard, independently of any capability it holds) and cannot mint another admin key (only an organization owner or admin session can issue one). No money-moving route admits it either, so in practice it provisions and reads but never spends or withdraws.

Provisioning a key per downstream customer is the basis of Pattern A whitelabelling.

Budgets and spend limits

Set spend-limit budgets at several levels: the whole organization, a workspace, an individual member, or a single key, each shown with a live spend bar. The organization-wide budget is always shown first so the overall limit is never buried. Managing budgets requires the budgets permission (owner, admin, or billing admin).