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)

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.
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.

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

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).