Skip to main content
PUT
Error
Required Permissions How permissions work

Authorizations

Authorization
string
header
required

Management API authentication for /api/* endpoints. Use the Authorization header with Bearer <token>, where <token> is one of:

  • a Bifrost management API key,
  • a dashboard session token issued by POST /api/session/login,
  • base64 of <admin-username>:<admin-password> (legacy equivalent of BasicAuth).

Virtual keys (sk-bf-*) and the x-api-key header are not accepted on management APIs - the sole exception is GET /api/governance/virtual-keys/quota, which is virtual-key-only.

Authentication alone is not sufficient in Bifrost Enterprise: each operation page shows a Required Permissions table (Resource:Operation, for example Dashboard:View) above its Authorizations section, and the caller's RBAC role or management API key scopes must include what it lists, otherwise the request is rejected with 403 Forbidden.

A local admin — authenticated with the admin password, or any caller on a deployment with dashboard auth disabled — bypasses these checks and can call every management endpoint.

OSS setup lock. On Bifrost OSS, while dashboard auth is not active (no admin account, or auth disabled), every management endpoint except the public ones (/health, /api/version, /api/session/is-auth-enabled, /api/session/login, ...) requires the operator's setup token in the X-Bifrost-Setup-Token header, in place of Authorization. The token is set with setup_token in config.json or the BIFROST_SETUP_TOKEN environment variable. A missing header returns 401, a wrong token 403. The header stops working once dashboard auth is enabled. The dashboard instead trades the token once for an HttpOnly bifrost_setup_session cookie via POST /api/session/setup. See Required permissions for how permissions are derived and which endpoints are exempt.

Path Parameters

vk_id
string
required

Virtual key ID

budget_id
string
required

ID of a budget owned by the virtual key

Body

application/json

Replaces the active override on one budget. The override is additive: it does not change the budget's max_limit, current_usage, or reset schedule. Sending this request against a budget that already has an override replaces that override entirely.

amount
number
required

Additional spend in dollars added on top of max_limit while the override is active. Must be greater than 0 and finite.

mode
enum<string>
required

cycles keeps the override active for cycles reset windows starting with the current one. forever keeps it active until it is removed with a DELETE.

Available options:
cycles,
forever
cycles
integer

Number of reset windows the override stays active for, counting the current window as the first. Required and must be greater than 0 when mode is cycles; must be omitted or 0 when mode is forever.

Required range: x >= 1

Response

Budget override applied successfully

The persisted budget and the additive limit now in force.

budget
object
required

Budget configuration

effective_max_limit
number
required

max_limit plus override_amount while an override is active; equal to max_limit otherwise.