Skip to main content
GET
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.

Query Parameters

scope_kind
enum<string>

Filter by scope kind Scope that determines which requests a pricing override applies to. The virtual_key* family is checked before the user* family during cost resolution, which is checked before the provider/global scopes; within a family, more identifiers present means a more specific match.

Available options:
global,
provider,
provider_key,
virtual_key,
virtual_key_provider,
virtual_key_provider_key,
user,
user_provider,
user_provider_key
user_id
string

Filter by user ID (for user* scopes)

virtual_key_id
string

Filter by virtual key ID (for virtual_key* scopes)

provider_id
string

Filter by provider ID

provider_key_id
string

Filter by provider key ID

Case-insensitive substring match against the pricing override name. A non-empty value switches the response to the paginated shape.

limit
integer

Maximum number of results to return. A non-empty limit, offset, or search value switches the response to the paginated shape.

Required range: x >= 0
offset
integer

Number of results to skip

Required range: x >= 0

Response

Successful response

When limit, offset, or search is supplied, count reflects the returned page while total_count reflects the full matching set. Otherwise (backward-compatible, non-paginated path) total_count equals count and limit/offset describe the full unpaged result.

pricing_overrides
object[]
count
integer

Number of overrides in this response

total_count
integer

Total number of overrides matching the filters

limit
integer

Page size used for this response

offset
integer

Offset used for this response