Skip to main content
GET
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.

Query Parameters

limit
integer
default:25

Maximum number of clients to return (1–100, default 25).

Required range: 1 <= x <= 100
offset
integer

Number of clients to skip.

Required range: x >= 0

Case-insensitive search by client name.

server
string

Filter to a single client by its exact client_id.

connection_type
string

Comma-separated connection types to include (OR semantics).

Example:

"http,sse"

auth_type
string

Comma-separated auth types to include (OR semantics).

Example:

"oauth,per_user_oauth"

state
string

Comma-separated runtime connection states to include (OR semantics), resolved against live engine state. Only healthy and unstable are meaningful filter values: healthy matches clients the engine currently reports as healthy; unstable matches everything else (error, pending states, needs_reauth, disabled, not present in the engine). Selecting both, or neither, applies no state filter. Note the response-only needs_reauth projection on per-user clients happens after filtering, so such clients still match healthy.

Example:

"healthy"

all_virtual_keys
boolean

When true, include clients that are open to all virtual keys (allow_on_all_virtual_keys). ORs with virtual_keys.

virtual_keys
string

Comma-separated virtual key IDs; includes clients explicitly assigned to any of them. ORs with all_virtual_keys.

code_mode
boolean

Filter by code-mode clients. Omit for no filter.

disabled
boolean

Filter by disabled status — true returns disabled clients, false returns enabled clients. Omit for no filter.

Response

Successful response

Paginated list of MCP clients.

clients
object[]
required
count
integer
required

Number of clients returned in this page

total_count
integer<int64>
required

Total number of clients matching the query (before pagination)

limit
integer
required

Page size used for the response

offset
integer
required

Page offset used for the response