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 to create a routing rule

name
string
required

Name of the routing rule

targets
object[]
required

Weighted routing targets; weights must sum to 1; target is selected probabilistically at request time

Minimum array length: 1
scope
enum<string>
default:global

Scope level for the rule. The team, customer or virtual key named by scope_id must exist (400 otherwise); a user scope_id is not checked.

Available options:
global
description
string

Optional description

enabled
boolean
default:true

Whether the rule is enabled

chain_rule
boolean
default:false

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

CEL expression for matching. Empty or omitted matches every request.

fallbacks
(string | object)[]

Ordered fallback chain, tried after the selected target fails

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
scope_id
string | null

ID for the scope. Required when scope is not global; stored as null for global.

priority
integer
default:0

Priority for rule evaluation (lower number = higher priority). Must be unique within the same scope and scope_id; a duplicate returns 409.

query
object | null

Visual rule tree structure

Response

Routing rule created successfully

Response containing created/updated routing rule

message
string
rule
object

CEL-based routing rule for intelligent request routing