> ## 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. # Reauthorize an MCP client against a newly registered OAuth client > Registers a replacement OAuth client (RFC 7591 Dynamic Client Registration) at the config's registration_url, writes it over the stored credentials, and then runs the same consent flow POST /api/mcp/client/{id}/reauthorize runs, against the new client. This exists for a provider that no longer recognises the client_id it issued, which is common with Dynamic Client Registration because the provider's client registry is often in memory and does not survive a restart. Once that happens the stored client_id is rejected at the token endpoint on every refresh and at the authorize endpoint on every reauthorization, so plain reauthorize cannot recover the connection. Replacing the client_id marks every credential stored under the OAuth config needs_reauth and stops using it, since none of them can be refreshed against a client the provider no longer associates them with. It does not revoke access tokens the provider already issued (Bifrost never calls the provider's revocation endpoint), so those can stay valid at the provider until they expire. For auth_type "per_user_oauth" that includes every end-user credential, not just the retained admin one, and each user must authenticate again. Plain reauthorize leaves end-user credentials untouched; this endpoint does not. Complete the returned flow exactly like reauthorize's: open authorize_url in a browser, poll status_url until "authorized", then POST complete_url. ## OpenAPI ````yaml /openapi/openapi.json post /api/mcp/client/{id}/reregister 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/mcp/client/{id}/reregister: post: tags: - MCP - OAuth summary: Reauthorize an MCP client against a newly registered OAuth client description: | Registers a replacement OAuth client (RFC 7591 Dynamic Client Registration) at the config's registration_url, writes it over the stored credentials, and then runs the same consent flow POST /api/mcp/client/{id}/reauthorize runs, against the new client. This exists for a provider that no longer recognises the client_id it issued, which is common with Dynamic Client Registration because the provider's client registry is often in memory and does not survive a restart. Once that happens the stored client_id is rejected at the token endpoint on every refresh and at the authorize endpoint on every reauthorization, so plain reauthorize cannot recover the connection. Replacing the client_id marks every credential stored under the OAuth config needs_reauth and stops using it, since none of them can be refreshed against a client the provider no longer associates them with. It does not revoke access tokens the provider already issued (Bifrost never calls the provider's revocation endpoint), so those can stay valid at the provider until they expire. For auth_type "per_user_oauth" that includes every end-user credential, not just the retained admin one, and each user must authenticate again. Plain reauthorize leaves end-user credentials untouched; this endpoint does not. Complete the returned flow exactly like reauthorize's: open authorize_url in a browser, poll status_url until "authorized", then POST complete_url. operationId: reregisterMCPClient parameters: - name: id in: path required: true description: MCP client ID schema: type: string responses: '200': description: | Reauthorization flow initiated against the newly registered client. Carries the same fields as reauthorize, plus registered_client_id and previous_client_id so the caller can confirm which client the consent it is about to run belongs to. content: application/json: schema: $ref: '#/components/schemas/OAuthFlowInitiation' '400': description: >- Client is not an OAuth-based auth type (oauth, per_user_oauth), has never completed initial OAuth authorization (use initiate-verification instead), the OAuth config has no registration_url, or the provider refused the registration request (answered it with a 4xx). Nothing is changed in any of these cases. A provider that could not be reached, or that answered with a 5xx, is a 500 instead content: application/json: schema: $ref: '#/components/schemas/BifrostError' '404': description: MCP client not found content: application/json: schema: $ref: '#/components/schemas/BifrostError' '500': description: > Internal failure. The message tells two cases apart, and they call for opposite responses. Nothing was changed in Bifrost: the stored client_id is what it was and no token was invalidated, whether the OAuth config could not be loaded, the provider's registration endpoint could not be reached or answered with a 5xx, or the replacement client could not be stored. Safe to retry. One of these leaves something behind at the provider: a message starting "failed to persist the newly registered oauth client" means the provider did register a replacement and only storing it locally failed, so the provider now holds a registration Bifrost will never use, and each retry adds one more. Bifrost cannot delete those (it implements no RFC 7592 client management); remove them at the provider if it lists registered clients. Every other message here means nothing was registered anywhere. The replacement was installed, but consent could not be started: registration and rotation are committed before the consent flow is opened, and the registration made at the provider cannot be undone. The new client_id is stored and every token bound to the config is already needs_reauth. The message says so and names both client_ids. Do NOT retry this endpoint, which would register yet another client: call POST /api/mcp/client/{id}/reauthorize, which runs consent against whatever client is stored, now the replacement. content: application/json: schema: $ref: '#/components/schemas/BifrostError' '503': description: OAuth provider not configured content: application/json: schema: $ref: '#/components/schemas/BifrostError' security: - ManagementBearerAuth: [] - BasicAuth: [] components: schemas: OAuthFlowInitiation: type: object description: Response when initiating an OAuth flow properties: status: type: string enum: - pending_oauth message: type: string oauth_config_id: type: string description: ID of the OAuth config created for this flow flow_id: type: string description: | ID of the flow row driving this consent. Returned by POST /api/mcp/client/{id}/reauthorize, whose OAuth config has been "authorized" since the client was first verified; pass it as the flow_id query parameter on status polls so they report this flow's own state rather than that stale bootstrap status. Create-time flows do not need it (their config starts "pending"). authorize_url: type: string description: URL to redirect the user to for authorization expires_at: type: string format: date-time description: When the OAuth authorization request expires mcp_client_id: type: string description: The MCP client ID that initiated this OAuth flow complete_url: type: string description: | Relative URL to POST once the flow is authorized (/api/mcp/client/{oauth_config_id}/complete-oauth). Note the path parameter is the oauth_config_id, not the MCP client ID. status_url: type: string description: | Relative URL to poll for the flow status (/api/oauth/config/{oauth_config_id}/status, with ?flow_id= appended for reauthorize flows). Wait for status "authorized" before calling complete_url. next_steps: type: array items: type: string description: >- Human-readable steps to complete the flow (authorize, poll, complete) registered_client_id: type: string description: > The OAuth client_id the provider issued for the replacement client, which is the one authorize_url runs consent against. Returned only by POST /api/mcp/client/{id}/reregister. This is the provider's OAuth client_id, not the MCP client ID in mcp_client_id. previous_client_id: type: string description: > The OAuth client_id that registered_client_id replaced. Returned only by POST /api/mcp/client/{id}/reregister. Equal to registered_client_id when the provider answered the registration with the client it already held, in which case nothing was replaced and no token was invalidated. 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' 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.