A valid request URL is required to generate request examples{
"allow": true,
"reason": "<string>",
"plugin_logs": [
{
"plugin_name": "<string>",
"level": "<string>",
"message": "<string>",
"timestamp": 123
}
]
}{
"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>"
}
}Inspect a request without forwarding it
Runs the pre-model plugin checks against a request and answers whether forwarding it upstream is allowed, without calling any provider. Intended for an intercepting proxy that holds the original request and needs a verdict before releasing it.
Plugins that mutate execution or depend on a provider call are skipped.
Unlike the inference routes, this endpoint takes its request context in
the body rather than in HTTP headers: entries in metadata are read as
the request’s headers, so {"x-bf-project-id": "..."} scopes the
inspected request to a governance project exactly as the header would.
When called with phase: "response" and log: true, the resolved
project is recorded on the log row this endpoint writes.
A valid request URL is required to generate request examples{
"allow": true,
"reason": "<string>",
"plugin_logs": [
{
"plugin_name": "<string>",
"level": "<string>",
"message": "<string>",
"timestamp": 123
}
]
}{
"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>"
}
}| Permission | Granted via |
|---|---|
| None | Not RBAC-gated - authorized by the credential below |
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
A request to evaluate, plus the context the caller would otherwise have sent as HTTP headers.
request evaluates before the upstream call; response reports the outcome afterwards, which is the phase that can write a log row.
request, response Write a log row for this call. Honoured on the response phase, where the row carries the resolved governance project.
The Bifrost request being inspected.
The upstream response, on the response phase.
Error response from Bifrost
Show child attributes
Show child attributes
Read as the inspected request's headers, lowercased. This is how a caller scopes the inspection to a governance project, with x-bf-project-id or x-bf-project-name.
Lines carried over from an earlier phase.
Show child attributes
Show child attributes
Was this page helpful?