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

Exactly one of config (an unsaved relay) or name (a saved one) selects the configuration to preview.

sample
object
required

One hypothetical relayed call - what the caller would send and what the upstream would answer. Bodies are the operator's own samples; nothing is fetched from the upstream.

name
string

Name of a saved relay to preview.

config
object

A relay as sent on create and update. Secrets may be plain text or env./vault. references.

Example:

Response

What the relay would record for the sample

What the relay would record for the sample call - the route it matched, whether it counts, what it read from each body, and the resulting cost.

route_index
integer | null

Index into routes[], null when no route matched.

route_allowed
boolean

False when no route matches and skip_route_check is off - the relay would answer 404.

billable
boolean
streams
boolean

Whether the call would be served by the streaming relay.

counted
boolean

Whether the call reports usage - billable and a 2xx status.

model_path
string
model_source
enum<string>
Available options:
,
body,
query
model
string
units_source
enum<string>
Available options:
,
response,
request
units_measure
enum<string>
Available options:
,
value,
chars,
body_bytes,
body_chars
units_path
string
units
number | null

Raw quantity read, null when none.

units_billed
number | null

Quantity after block rounding and the minimum, null when none.

units_block_size
number
units_minimum
number
cost_per_unit
number
cost_per_request
number
extracted_cost
number | null

Value read at cost_path, null when none.

tokens
object | null
cost
number

What the log row and budgets would carry.

notes
string[]

Why a field came out empty, or what the relay would do with this call.