Skip to main content

Overview

Passthrough integrations let you call provider-native API paths and payloads through Bifrost without route-level request/response conversion. When you use passthrough endpoints, the request still flows through Bifrost core logic. You keep Bifrost features such as logging and observability while sending provider-native paths and bodies.

Endpoints

  • /openai_passthrough Default provider: openai
  • /anthropic_passthrough Default provider: anthropic
  • /azure_passthrough Default provider: azure
  • /genai_passthrough Default provider: gemini (with automatic Vertex detection for clients configured to use Vertex)
  • /bedrock_passthrough Default provider: bedrock (restricted to three operations, see Bedrock Passthrough)

How It Works

  1. Send your request to a passthrough endpoint (OpenAI, Anthropic, Azure, or GenAI passthrough).
  2. The integration strips the passthrough prefix and forwards the remaining provider-native path/body.
  3. Bifrost picks the provider key. Client-supplied provider credentials (authorization, api-key, x-api-key, x-goog-api-key) are stripped from the request, and Bifrost selects a key from its own key config for the resolved provider and model.
  4. Bifrost handles provider execution through core inference and plugin pipelines.
  5. Response status, headers, and body are returned as passthrough output (for both stream and non-stream requests).
Authenticate to Bifrost with your Bifrost virtual key, not your provider API key. Passthrough is not a credential proxy — provider keys in the incoming request are never forwarded upstream. Bifrost always injects the key it selects from its configured keys.
When the URL path names a model (for example models/{model} or a deployment path), Bifrost uses that model. Otherwise, for JSON bodies, it reads the model from the top-level model key, the same key the provider reads. Virtual-key model restrictions apply to whichever model was resolved. A JSON body must carry that key at most once, spelled exactly model (lowercase), with a string value; a body that repeats it (in any letter case), spells it differently, gives it a non-string value, or is not valid JSON while sent as application/json is rejected with 400. Bodies without a model key and multipart bodies are unaffected.
Claude Code OAuth sign-in (Authorization: Bearer sk-ant-oat…) is handled separately on the regular /anthropic route, where Bifrost forwards the caller’s token instead of selecting a key. Point Claude Code there — no passthrough endpoint needed. See Claude Code authentication.

Provider Selection Rules

OpenAI Passthrough

  • Uses openai as the default provider.

Anthropic Passthrough

  • Uses anthropic as the default provider.

Azure Passthrough

  • Uses azure as the default provider.
  • Requires an Azure key with endpoint configured.
  • api-version handling varies by route:
    • /openai/deployments/ routes: if the caller omits api-version, Bifrost injects a default (2025-04-01-preview). Pass your own api-version to override — for example, to pin to a GA version or use a specific preview version.

Bedrock Passthrough

  • Uses bedrock as the default provider.
  • Not a general AWS proxy. Bifrost forwards only the Bedrock operations it has no native route for, and refuses every other path, method or malformed identifier with a 400 before any request is built:
  • Identifiers follow the character sets AWS documents for each parameter: agent, alias, knowledge-base and guardrail ids are alphanumeric, a session id may also contain ., _, : and - (but never consists only of dots), and a guardrail version is DRAFT or a number from 1 to 8 digits. An ARN is not accepted in place of an id.
  • The host comes from the key’s region (or its endpoints overrides). Credentials in the incoming request are never forwarded. InvokeAgent and Retrieve are always signed with the key’s AWS credentials (SigV4, service bedrock), because AWS does not accept Bedrock API keys for Agents Runtime operations: a key that holds only an API key is refused with a 400 for those two operations, so select a key that has an access key and secret key or a role (for example with x-bf-api-key). ApplyGuardrail sends the key’s Bedrock API key as a bearer token when it has one, and is SigV4-signed otherwise.
  • The AWS status and body come back unchanged, together with the response headers Bifrost forwards, including Content-Type and X-Amzn-* such as X-Amzn-Errortype and X-Amzn-Requestid. Transport-level headers (for example Content-Length, Content-Encoding, Transfer-Encoding, Connection and Date) and credential-bearing ones (Set-Cookie, anything that looks like an API key or secret, and X-Amzn-Oidc-*) are removed, so an upstream ResourceNotFoundException still reaches the caller with its exception type. InvokeAgent is forwarded to the client as AWS produces it, so a long agent run is not buffered and is not bound by the gateway’s whole-response timeout (only a stalled connection ends it, via the stream idle timeout). Retrieve and ApplyGuardrail are returned as a single response.

GenAI Passthrough

  • Uses gemini by default.
  • Automatically switches to vertex when Vertex patterns are detected, such as:
    • URL path containing /projects/{PROJECT_ID}/locations/{LOCATION}/
    • Request body model containing a Vertex resource path
    • OAuth token pattern typically used for Vertex (Bearer ya29...)

Usage Examples

OpenAI Passthrough

Anthropic Passthrough

Azure Passthrough

Bedrock Passthrough

GenAI Passthrough (Gemini)

GenAI Passthrough (Vertex-style request)


Notes

  • Use passthrough when you need a provider endpoint that is not directly supported by Bifrost integration routes yet.
  • Provider key selection is done by Bifrost, not by the caller. On every passthrough endpoint, the client’s authorization, api-key, x-api-key, and x-goog-api-key headers are dropped before the request leaves Bifrost, and the upstream auth header (including Azure’s api-key / OAuth token) is set from the Bifrost key config.
  • The only exception is direct API keys, which need both the server-side allow_direct_keys setting and a per-request x-bf-direct-key: true header. Without both, a raw provider key in the request is ignored.
  • For Azure /openai/deployments/ routes, Bifrost injects api-version=2025-04-01-preview when the caller does not supply one. Supply your own api-version query parameter to use a different version (e.g. 2024-10-21 for the latest GA, or a newer preview).