A valid request URL is required to generate request examples{
"message": "<string>",
"rule": {
"scope": "global",
"id": "<string>",
"name": "<string>",
"description": "<string>",
"enabled": true,
"cel_expression": "<string>",
"targets": [
{
"weight": 0.5,
"provider": "<string>",
"model": "<string>",
"key_id": "<string>"
}
],
"fallbacks": [
"<string>"
],
"scope_id": "<string>",
"priority": 123,
"query": {},
"created_at": "2023-11-07T05:31:56Z",
"updated_at": "2023-11-07T05:31:56Z"
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>"
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>"
}
}Create routing rule
Creates a new CEL-based routing rule for intelligent request routing. Provider and model can be left empty to use the incoming request values.
A valid request URL is required to generate request examples{
"message": "<string>",
"rule": {
"scope": "global",
"id": "<string>",
"name": "<string>",
"description": "<string>",
"enabled": true,
"cel_expression": "<string>",
"targets": [
{
"weight": 0.5,
"provider": "<string>",
"model": "<string>",
"key_id": "<string>"
}
],
"fallbacks": [
"<string>"
],
"scope_id": "<string>",
"priority": 123,
"query": {},
"created_at": "2023-11-07T05:31:56Z",
"updated_at": "2023-11-07T05:31:56Z"
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>"
}
}{
"event_id": "<string>",
"type": "<string>",
"is_bifrost_error": true,
"status_code": 123,
"error": {
"type": "<string>",
"code": "<string>",
"message": "<string>",
"param": "<string>",
"event_id": "<string>"
},
"extra_fields": {
"provider": "anthropic",
"model_requested": "<string>",
"request_type": "<string>",
"error_type": "<string>"
}
}Authorizations
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 ofBasicAuth).
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
- Option 1
- Option 2
Request to create a routing rule
Scope level for the rule
global Name of the routing rule
CEL expression for matching
Weighted routing targets; weights must sum to 1; target is selected probabilistically at request time
1Show child attributes
Show child attributes
Priority for rule evaluation (lower number = higher priority)
Optional description
Whether the rule is enabled
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.
1ID for the scope (required if scope is not global)
Visual rule tree structure
Was this page helpful?