Skip to main content

​
Overview

Bifrost management API endpoints are the endpoints that interact directly with Bifrost itself, instead of sending inference requests to model providers. These include APIs for RBAC, governance, users, teams, virtual keys, providers, plugins, logs, configuration, and similar control-plane operations. Use an API key as the bearer token when calling these endpoints from scripts, backend services, CI jobs, or other automation.

​
Create An API Key

  1. Open the Bifrost dashboard.
  2. Go to Settings > API Keys.
  3. Click Create API Key.
  4. Give the key a recognizable name. Assign the scopes based on the permissions you would like to give the key.
  5. Create the key.
  6. Copy the generated key and store it in your secret manager.
Keys can also be managed over the API itself — see Create an API key. A key’s access comes from its scopes alone and never inherits the creator’s role, and you can only grant scopes you already hold yourself.
Copy the generated key when it is shown and follow general security practices.

​
Required Permissions

Every management endpoint in the API reference shows a Required Permissions table above its Authorizations section, listing each permission as Resource:Operation (for example Dashboard:View). You do not need to work it out from the URL: open the endpoint page and grant exactly what the table lists. One permission catalog backs both ways of calling the management API: A request whose role or key lacks the permission is rejected with 403 Forbidden.

​
How a permission is derived

  • Resource is taken from the URL. It is usually the first segment after /api/ (/api/webhooks/... requires Webhooks), but several paths map to a different resource. For example, /api/logs/stats, /api/logs/histogram/*, and /api/logs/rankings* require Dashboard, not Logs, and /api/governance/audit-logs* requires AuditLogs, not Governance.
  • Operation defaults to the HTTP method: GET requires View, POST requires Create, PUT and PATCH require Update, and DELETE requires Delete. A few endpoints override this, for example POST /api/logs/recalculate-cost requires Logs:Update and POST /api/license requires Settings:Update.
Because these rules have exceptions, always rely on the Required Permissions table on the endpoint page rather than the URL.

​
Endpoints that list no permission

  • Public endpoints (for example GET /health, GET /api/version, POST /api/session/login) require no authentication.
  • Exempt endpoints (for example GET /api/config, POST /api/session/ws-ticket, GET /api/governance/users/me/permissions) require authentication but skip the permission check, so any authenticated management caller can use them.
  • Not RBAC-gated endpoints authenticate with the credential itself rather than a role or scope, such as GET /api/governance/virtual-keys/quota, which accepts only a virtual key.
Permissions and API key scopes are enforced in Bifrost Enterprise. Open-source Bifrost has no per-endpoint permissions: any caller that passes management authentication (the admin password or a dashboard session) can use every management endpoint.
A local admin who signs in with the admin password bypasses RBAC entirely. Separately, Data Access Control can narrow which rows a permitted caller sees, for example the logs behind /api/logs/stats, without changing the permission the endpoint requires.

​
Management API Endpoints

Use this bearer token for management API endpoints that configure or inspect Bifrost. The following endpoint patterns use management API authentication in the OpenAPI spec.
The /api/routing/* routes are available in Bifrost v2.0.0 and above. On earlier versions the routing endpoints live under /api/governance/*.
Governance resources moved under the /api/governance namespace. Both generations are listed: the canonical route is the one to build against, and the rows marked deprecated aliases are the pre-move paths, which still answer today and are scheduled for removal in the following major release. See the v2.0.0 migration guide for the full mapping.