Authentication

API keys

Create keys in a project's API Keys page. Each key belongs to exactly one project and environment, and inherits the Directives of its team, project, and environment; it can carry Directives of its own too. Owners and admins can create and revoke keys. Name each key after the service or agent that holds it, such as inference-bureau-api: names are unique among a project's active keys, and Logs filter by them (key = inference-bureau-api).

Keys in a production environment look like ib_live_…, and keys in development like ib_test_…. The prefix is only a label: both reach the same models and are billed the same way. The full key is shown once at creation and stored hashed, so it can't be shown again. The dashboard keeps the first characters so you can tell keys apart.

Tick Auditor Permissions when creating a key that should also set up Auditor through the API and the Auditor CLI. Other keys can call every inference endpoint, but not the Auditor repository routes.

Sending the key

Send the key as a bearer token. OpenAI SDKs do this for you when you pass apiKey. The key is also accepted in x-api-key, which is what the Anthropic SDK sends to /v1/messages; when both headers are present, Authorization wins.

Authorization: Bearer $IB_API_KEY

A missing, malformed, revoked, expired or paused key returns 401 invalid_api_key. A key whose project or environment is disabled returns 403 policy_denied, and a suspended team 403 account_suspended. See Errors.

Read logged content

When the Log content Directive keeps prompts and responses, an ordinary key can't read them. Tick Read logged content when creating a key, or send "permissions": ["content:read"] to Create a key, and the key can call GET /v1/requests/:id/content for requests of its own project, in any of the project's environments; never another project's or team's. It is off by default, kept when the key is rotated, shown on the key's row as Reads content, and can be turned on or off later from the key's Permissions on the API Keys page or with PATCH /v1/keys/:id. Each read is recorded in the audit log as request.content.view under the key. Management keys can't hold it.

Expiry and rotation

A key can expire: pick Expires when you create it (7, 30 or 90 days, a year, or never). After that time it gets 401 invalid_api_key and shows as expired. Rename changes a key's name without changing its secret. Rotate issues a new secret, under a new key with the same name, environment, Directives and permissions, and keeps the old one working for an overlap you choose (now, an hour, a day or a week), so you can deploy the new secret before the old one stops. The new secret is shown once, like a new key's.

Revoking a key

Choose Revoke next to the key on the API Keys page. Revocation takes effect on the next request: the key is checked on every request and again just before each provider attempt, so a request admitted but not yet sent to a provider is stopped too. Requests a provider is already answering finish normally. Revoked keys stay listed under Show revoked, and their requests stay in Logs.

Pausing a key

Choose Pause next to the key to stop it without losing it: its requests get 401 invalid_api_key, checked the same way as a revocation, but the secret, Directives and budgets are kept, so Resume makes the same key work again with no change on the caller's side. A paused key is marked on its row with why it was paused. Keys are also paused for you when Pause keys on unusual spend is on and a key's last hour of spend was far above its usual, and when a key is found published (below). Every pause sends a key.paused webhook; the management API has pause and resume too. A paused key can still be renamed, rotated or revoked; the key a rotation makes is not paused.

Leaked keys

Inference Bureau is joining GitHub's secret scanning partner program for ib_live_, ib_test_ and ib_mgmt_ keys. Once that is live, a key GitHub finds in a public repository or gist is paused if it is a project key and revoked if it is a management key (which could make more keys), and the team's owners, admins and billing contacts are emailed with where it was found. A key.compromised webhook is sent too. Rotate a found key and revoke the old one; resume it only if it was published on purpose.

Management keys

To create, rotate and revoke keys, edit Directives or add webhooks from Terraform, CI or your own platform (a key per customer, say), create a management key under Team → Management keys. It starts with ib_mgmt_, belongs to the team, and works only on the management API: it can't call models or read usage, and project keys can't manage. Owners and admins create, rotate and revoke them; every change made with one is in the audit log under that key. A management key changes the team's own Directives only if it was created with the Team Directives permission, which is off by default: the team's Directives are the ceiling for every project, so keep that permission for the one tool that manages it.

Keep keys server-side