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

rule_id
string
required

Routing rule ID

Body

application/json

Request to update a routing rule (all fields optional; providing targets replaces all existing targets)

name
string

New name. An empty string is ignored.

description
string
enabled
boolean
chain_rule
boolean

When true, a match does not end evaluation: the rule's resolved provider and model become the new context and every rule is evaluated again from the top. Each rule fires at most once per request, up to the chain's maximum depth (default 10).

cel_expression
string
targets
object[]

Replaces all existing targets when provided; weights must sum to 1

Minimum array length: 1
fallbacks
(string | object)[]

Replaces the fallback chain when provided; send an empty array to clear it.

A fallback in a routing rule's chain. Either the "provider/model" string ("provider/" keeps the incoming model), or an object that additionally pins a provider key.

Minimum string length: 1
priority
integer

Must stay unique within the rule's scope and scope_id; a conflict returns 409.

scope
enum<string>

Moves the rule to another scope. An empty string is ignored. A scope other than global needs a scope_id, sent here or already stored; global clears scope_id.

Available options:
global,
team,
customer,
virtual_key,
user
scope_id
string | null

New scope ID, checked against the scope when scope or scope_id is sent.

query
object | null

Response

Routing rule updated successfully

Response containing created/updated routing rule

message
string
rule
object

CEL-based routing rule for intelligent request routing