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

Body

application/json

Request body for creating a pricing override.

name
string
required

Human-readable label

scope_kind
enum<string>
required

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
match_type
enum<string>
required
Available options:
exact,
wildcard
pattern
string
required

Model name or wildcard prefix ending with * (e.g. "claude-3*")

request_types
enum<string>[]
required

Request types this override applies to. At least one value is required.

Minimum array length: 1

Request type for pricing override filtering. Stream variants are treated identically to their base type - specifying chat_completion covers both streaming and non-streaming chat requests.

Available options:
chat_completion,
text_completion,
responses,
embedding,
rerank,
speech,
transcription,
image_generation,
image_variation,
image_edit,
video_generation,
video_remix
user_id
string

Required for user* scopes

virtual_key_id
string

Required for virtual_key* scopes

provider_id
string

Required for provider, virtual_key_provider, and user_provider scopes

provider_key_id
string

Required for provider_key, virtual_key_provider_key, and user_provider_key scopes

patch
object

Pricing fields to override. All non-null fields are applied. Usage-based values are costs per unit in USD. cost_per_request is a flat fee in USD applied once per billed request.

Response

Pricing override created successfully

message
string
pricing_override
object

A pricing override that applies custom rates to matching requests.