> ## Documentation Index > Fetch the complete documentation index at: https://bifrost-dev.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Update Warp configuration > Writes Warp's settings. **Administrators only.** A single write points the server at a provider key and a model it will then call on its own behalf, which is not something an ordinary dashboard user should be able to do. In OSS only the local admin may write; in enterprise the caller needs `Warp` Update. Anyone else gets `403`. The response carries the key reference back, not a redacted credential - there is no secret stored here to redact. `api_key_id` is a reference, not a credential, so it round-trips in the clear and needs no omitted-versus-empty rule: omitting it writes an empty value and clears the stored reference. `provider` and `model` are Warp's default model. `additional_models` lists the others a chat request may name, so this write is also what decides which models dashboard users can switch between: they pick among what is stored here and cannot add to it. ## OpenAPI ````yaml /openapi/openapi.json put /api/warp/config openapi: 3.1.0 info: title: Bifrost API description: > Bifrost HTTP Transport API for AI model inference and gateway management. This API provides a unified interface for interacting with multiple AI providers including OpenAI, Anthropic, Bedrock, Gemini, and more through a single API, along with comprehensive management APIs for configuring and monitoring the gateway. ## API Structure ### Unified Inference API (`/v1/*`) The primary API using Bifrost's unified format. Model parameters use the format `provider/model` (e.g., `openai/gpt-4`, `anthropic/claude-3-opus`). ### Async Inference API (`/v1/async/*`) Submit inference requests for asynchronous execution. Returns a job ID immediately and allows polling for results. Supports all inference types except batches, files, and containers. ### Provider Integration APIs Native provider-format APIs for drop-in compatibility: - `/openai/*` - OpenAI-compatible API - `/anthropic/*` - Anthropic-compatible API - `/genai/*` - Google GenAI (Gemini) compatible API - `/bedrock/*` - AWS Bedrock compatible API - `/cohere/*` - Cohere compatible API ### Framework Integration APIs Multi-provider proxy endpoints for AI frameworks: - `/litellm/*` - LiteLLM proxy with all provider formats - `/langchain/*` - LangChain compatible endpoints - `/pydanticai/*` - PydanticAI compatible endpoints ### Management APIs (`/api/*`) APIs for managing and monitoring the Bifrost gateway: - `/api/config` - Configuration management - `/api/providers` - Provider and API key management - `/api/plugins` - Plugin management - `/api/governance/*` - Virtual keys, teams, customers, budgets, rate limits, routing rules, and pricing overrides - `/api/logs` - Log search and analytics - `/api/mcp/*` - MCP (Model Context Protocol) client management - `/api/session/*` - Authentication and session management - `/api/cache/*` - Cache management - `/health` - Health check endpoint ## Fallbacks Requests can include fallback models that will be tried if the primary model fails. version: 1.0.0 contact: name: Contact Us url: https://getmaxim.ai/bifrost license: name: Apache 2.0 url: https://opensource.org/licenses/Apache-2.0 servers: - url: '{baseUrl}' description: Your Bifrost instance variables: baseUrl: default: http://localhost:8080 description: Base URL of your Bifrost instance (e.g. https://bifrost.mycompany.com) security: - BearerAuth: [] - BasicAuth: [] - ApiKeyAuth: [] tags: - name: Models description: Model listing and information - name: Chat Completions description: Chat-based text generation - name: Text Completions description: Text completion generation - name: Responses description: OpenAI Responses API compatible endpoints - name: OCR description: Optical character recognition for documents and images - name: Rerank description: Document reranking by relevance to a query - name: Decisions description: Structured decisions evaluated against annotated function-tool definitions - name: Embeddings description: Text embedding generation - name: Images description: Image generations, editing, and variations - name: Videos description: Video generation and management - name: Audio description: Speech synthesis and transcription - name: Count Tokens description: Token counting utilities - name: Batch description: Batch processing operations - name: Files description: File management operations - name: Containers description: Container management operations - name: Async Jobs description: Asynchronous job submission and retrieval endpoints - name: Realtime description: Realtime WebSocket and WebRTC endpoints - name: OpenAI Integration description: OpenAI-compatible API endpoints (/openai/*) - name: Azure Integration description: Azure OpenAI integration endpoints - name: Anthropic Integration description: Anthropic-compatible API endpoints (/anthropic/*) - name: GenAI Integration description: Google GenAI (Gemini) compatible API endpoints (/genai/*) - name: Bedrock Integration description: AWS Bedrock compatible API endpoints (/bedrock/*) - name: Cohere Integration description: Cohere compatible API endpoints (/cohere/*) - name: Typesafe Integration description: Typesafe compatible API endpoints (/typesafe/*) - name: LiteLLM Integration description: LiteLLM proxy endpoints with multi-provider support (/litellm/*) - name: LangChain Integration description: LangChain compatible endpoints with multi-provider support (/langchain/*) - name: PydanticAI Integration description: >- PydanticAI compatible endpoints with multi-provider support (/pydanticai/*) - name: Health description: Health check endpoints - name: Configuration description: Configuration management endpoints - name: Session description: Session and authentication endpoints - name: Providers description: Provider management endpoints - name: Plugins description: Plugin management endpoints - name: MCP description: Model Context Protocol endpoints - name: Governance description: Virtual keys, teams, and customers management - name: Routing description: Routing rules and complexity analyzer configuration - name: Logging description: Log search and management endpoints - name: Cache description: Cache management endpoints - name: Vault description: Vault secret management endpoints - name: Skills description: Skills Repository management, marketplace, and download endpoints - name: Audit Logs description: >- CADF-compliant audit log search, export, and signature verification endpoints - name: Webhooks description: Webhook endpoint management and signed async-job delivery history - name: Notifications description: >- Role-targeted dashboard notifications, delivered over the dashboard WebSocket - name: Background Jobs description: >- Status, progress and cancellation of durable background jobs (cost recalculation, Warp log indexing, and others) - name: Warp description: >- Configuration for Warp, the dashboard agent that answers questions about the deployment's own telemetry paths: /api/warp/config: put: tags: - Warp summary: Update Warp configuration description: > Writes Warp's settings. **Administrators only.** A single write points the server at a provider key and a model it will then call on its own behalf, which is not something an ordinary dashboard user should be able to do. In OSS only the local admin may write; in enterprise the caller needs `Warp` Update. Anyone else gets `403`. The response carries the key reference back, not a redacted credential - there is no secret stored here to redact. `api_key_id` is a reference, not a credential, so it round-trips in the clear and needs no omitted-versus-empty rule: omitting it writes an empty value and clears the stored reference. `provider` and `model` are Warp's default model. `additional_models` lists the others a chat request may name, so this write is also what decides which models dashboard users can switch between: they pick among what is stored here and cannot add to it. operationId: updateWarpConfig requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/WarpConfigInput' responses: '200': description: The updated configuration content: application/json: schema: $ref: '#/components/schemas/WarpConfig' '400': description: Bad request content: application/json: schema: $ref: '#/components/schemas/BifrostError' '403': description: >- Caller is not the local admin (OSS) and lacks `Warp` Update (enterprise) '409': description: Embedding configuration cannot change during an active backfill '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/BifrostError' '503': description: Config store not available content: application/json: schema: $ref: '#/components/schemas/BifrostError' security: - ManagementBearerAuth: [] components: schemas: WarpConfigInput: type: object description: > The write body. Only a config that claims to be usable has to be complete: when `enabled` is false, `provider` and `model` may be empty, so an operator can fill the form in over more than one sitting. Switching `enabled` on is what makes the rest required - see the conditional below, which mirrors what the server enforces so a generated client learns the rule from the schema rather than from a rejected request. if: properties: enabled: const: true required: - enabled then: required: - provider - model - embedding_provider - embedding_model - embedding_dimension properties: provider: minLength: 1 pattern: \S model: minLength: 1 pattern: \S embedding_provider: minLength: 1 pattern: \S embedding_model: minLength: 1 pattern: \S embedding_dimension: minimum: 1 properties: enabled: type: boolean default: false provider: type: string description: > Required when `enabled` is true, and must name a provider registered in this Bifrost deployment - the built-in providers plus any custom ones it has registered. There is deliberately no fixed enum: the registry is per-deployment, so an enum would reject valid custom provider names. An unregistered name is rejected with `400`. example: openai model: type: string description: Required when `enabled` is true. example: gpt-4o api_key_id: type: string description: > Which of the provider's configured keys Warp should use. Empty is valid and common: a provider on a trusted network, or one using ambient IAM credentials, needs no key at all. additional_models: type: array description: > The models to expose beside the default (`provider` and `model` above). Replaced whole on every write, like the default itself: leaving the field out clears the list. Every entry must be complete whether or not `enabled` is true, must name a registered provider, and must not repeat the `provider` and `model` of the default or of another entry. Any of those is rejected with `400`. maxItems: 20 items: $ref: '#/components/schemas/WarpModel' max_iterations: type: integer minimum: 0 maximum: 20 description: Zero means "use the default". request_timeout_seconds: type: integer minimum: 0 description: Zero means "use the default". history_retention_days: type: integer minimum: 0 description: > How long a saved chat is kept after its last turn. Zero means "use the default"; there is no maximum, because the per-owner conversation cap already bounds the table and how long a transcript stays readable is a policy question with no technically correct ceiling. system_prompt_suffix: type: string embedding_provider: type: string description: Required when `enabled` is true. embedding_model: type: string description: Required when `enabled` is true. embedding_api_key_id: type: string embedding_dimension: type: integer minimum: 0 description: Must be positive when `enabled` is true. log_vector_store_namespace: type: string default: BifrostWarpLogs semantic_search_threshold: type: number minimum: 0 maximum: 1 default: 0.8 description: > Zero means "use the default". ValidateConfigInput resolves an explicit zero before validating, so the write is accepted; the resolved value on WarpConfig keeps the positive bound. semantic_search_limit: type: integer minimum: 0 maximum: 25 default: 10 description: Zero means "use the default", resolved before validation. WarpConfig: type: object description: > Warp's deployment-wide settings, as returned by the read API. The stored provider credential is never included. `api_key_id` names which of the provider's configured keys Warp uses - a reference, not a secret, so the settings form can render "configured" without the key itself ever leaving the server: a dashboard session is a weaker credential than the provider key it would otherwise reveal. properties: configured: type: boolean description: > Whether Warp has everything it needs to answer a question: enabled, with a provider and a model, and an embedding space - embedding provider, embedding model, a positive embedding dimension and a namespace - since semantic search over the logs is part of answering. A key is deliberately not part of this test, since a provider using ambient credentials legitimately needs none. enabled: type: boolean description: Whether the operator has switched Warp on. provider: type: string description: > The provider of Warp's default model, e.g. `openai`. The default answers every chat request that names no model. example: openai model: type: string description: Warp's default model. example: gpt-4o api_key_id: type: string description: > Which of the provider's configured keys the default model uses. A reference, not a credential, so it round-trips in the clear - there is nothing here worth redacting. Empty when the provider needs no key. additional_models: type: array description: > The other models an operator has exposed. A chat request may name any of them, or the default, by `provider` and `model`; nothing else is accepted. Omitted when only the default is configured. maxItems: 20 items: $ref: '#/components/schemas/WarpModel' max_iterations: type: integer description: > How many times Warp may call tools and feed the results back before it must answer with what it has. Resolved value, so a row that never set one reports the default rather than zero. minimum: 1 maximum: 20 default: 8 request_timeout_seconds: type: integer description: Bound on a single upstream call. Resolved value. default: 120 history_retention_days: type: integer description: > How long a saved chat is kept after its last turn. Resolved value, so a row that never set one reports the default rather than zero. Deliberately separate from `logs_store.retention_days`: how long request telemetry is worth storing and how long someone's conversations stay theirs to reopen are different questions, and one number cannot answer both without either discarding transcripts early or keeping logs late. minimum: 1 default: 30 system_prompt_suffix: type: string description: > Appended to Warp's built-in system prompt. Additive only: an operator can teach Warp local naming conventions, but cannot remove the tool-use and scoping instructions the built-in prompt establishes. embedding_provider: type: string description: Provider used to embed gateway conversations for semantic search. example: openai embedding_model: type: string description: Embedding model used for both indexing and queries. example: text-embedding-3-small embedding_api_key_id: type: string description: >- Optional reference to one of the embedding provider's configured keys. embedding_dimension: type: integer minimum: 0 example: 1536 log_vector_store_namespace: type: string default: BifrostWarpLogs semantic_search_threshold: type: number exclusiveMinimum: 0 maximum: 1 default: 0.8 semantic_search_limit: type: integer minimum: 1 maximum: 25 default: 10 vector_store_connected: type: boolean readOnly: true description: Whether the shared runtime vector store is connected. required: - configured - enabled - provider - model - max_iterations - request_timeout_seconds - history_retention_days - embedding_provider - embedding_model - embedding_dimension - log_vector_store_namespace - semantic_search_threshold - semantic_search_limit - vector_store_connected BifrostError: type: object description: Error response from Bifrost properties: event_id: type: string type: type: string is_bifrost_error: type: boolean status_code: type: integer error: $ref: '#/components/schemas/ErrorField' extra_fields: $ref: '#/components/schemas/BifrostErrorExtraFields' WarpModel: type: object description: > One provider and model pair Warp may run on, with the provider key it is pinned to. The pair is what identifies an entry: a chat request names the model it wants by `provider` and `model`, so no two entries may share both. properties: provider: type: string description: A provider registered in this Bifrost deployment. minLength: 1 pattern: \S example: anthropic model: type: string minLength: 1 pattern: \S example: claude-sonnet-5 api_key_id: type: string description: > Which of the provider's configured keys this model uses. A reference, not a credential. Omitted when the provider's whole key pool is used. required: - provider - model ErrorField: type: object properties: type: type: string code: type: string message: type: string param: type: string event_id: type: string BifrostErrorExtraFields: type: object properties: provider: $ref: '#/components/schemas/ModelProvider' model_requested: type: string request_type: type: string error_type: type: string description: >- Normalized, low-cardinality classification of why the request failed, declared by whichever component refused it. Prefixed by fault domain (caller_, policy_, provider_, bifrost_). Absent on failures that were not classified at source. retry_after_ms: type: integer format: int64 minimum: 1000 maximum: 300000 description: >- The provider's hint for how long to wait before retrying, in milliseconds, read from its retry-after-ms or Retry-After header or its google.rpc.RetryInfo error detail, and clamped to between 1000 and 300000. Absent when the provider gave no explicit hint. ModelProvider: type: string description: AI model provider identifier enum: - anthropic - azure - bedrock - bedrock_mantle - cerebras - cohere - deepseek - gemini - groq - mistral - ollama - opencode-go - opencode-zen - openai - parasail - perplexity - sgl - vertex - openrouter - elevenlabs - huggingface - nebius - xai - replicate - vllm - runway - runware - fireworks - sarvam - wafer - databricks - typesafe securitySchemes: BearerAuth: type: http scheme: bearer description: > Bearer token authentication. Use your provider API key or Bifrost authentication token. Virtual keys (prefixed with `sk-bf-`) can also be passed here. BasicAuth: type: http scheme: basic description: > Basic authentication using the Bifrost admin username and password (`auth_config.admin_username` / `auth_config.admin_password`). Accepted on management APIs (`/api/*`, `/metrics`, `/ws`) only - the inference middleware never validates Basic credentials. ApiKeyAuth: type: apiKey in: header name: x-api-key description: | API key authentication via the `x-api-key` header. Virtual keys (prefixed with `sk-bf-`) can also be passed here. ManagementBearerAuth: type: http scheme: bearer description: > Management API authentication for `/api/*` endpoints. Use the `Authorization` header with `Bearer `, where `` is one of: - a Bifrost management API key, - a dashboard session token issued by `POST /api/session/login`, - base64 of `:` (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](/api/procuring-api-keys#required-permissions) for how permissions are derived and which endpoints are exempt. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.