The Management API lets you create and administer your organization’s API keys programmatically, instead of clicking through the dashboard. Use it to issue a unique key for each customer or employee, rotate keys on a schedule, cap spend per key, and track usage per key. It is authenticated by a separate management key, so the credential that provisions keys is never one that can make model calls.
A management key is a provisioning credential. It authenticates the Management API and nothing else.
Create one in the dashboard under Settings → API keys → Management keys. The raw key (prefixed mgmt_) is shown once at creation, so copy it then. Only a hash is stored, so it cannot be retrieved later.
A management key is scoped to one organization:
A management key returns 401 if used against the model endpoints. Keep it server-side, treat it like any other secret, and rotate it if it leaks.
All Management API requests are relative to:
Authenticate with the management key as a bearer token on every request:
POST /v1/keys mints a new API key and returns the raw key (prefixed mg_) exactly once. Pass an optional limit in USD and a limit_reset window to attach a spend cap.
The response is a key object. key is present only on creation:
hash is the stable identifier you use in every other call. It is a one-way hash, not the secret, so it is safe to store and log.
GET /v1/keys returns the org’s keys with current usage. It supports offset and limit query parameters, up to 100 keys per page.
Address a single key by its hash:
GET /v1/keys/{hash} returns one key with its usagePATCH /v1/keys/{hash} updates name, disabled, limit, or limit_resetDELETE /v1/keys/{hash} revokes the keyDeleting a key revokes it immediately but keeps its historical spend, so it still appears in usage reporting. To stop a key from being used without losing it, set disabled: true instead.
Attach a budget to any key with limit, a dollar amount, and limit_reset, one of daily, weekly, or monthly. The gateway sums the key’s spend over the current window and rejects requests with HTTP 402 once the cap is reached. The window resets at midnight UTC.
Every key object reports usage, the spend in the current window, and limit_remaining, so you can show a customer their remaining balance or alert before they hit the cap. You can also set a spend limit when creating a key in the dashboard. For org-wide and project-level budgets, see Cost governance and savings.
Spend is tracked per key, which is effectively per customer or per employee since each key records who created it. The By API key tab in Usage & spend lists each key’s requests, tokens, and spend, and a per-key detail view breaks spend down by model, provider, and project.
Name keys when you create them, for example customer-acme or [email protected]. The usage view and key list show the name, which makes per-customer and per-employee tracking readable at a glance.