> ## Documentation Index
> Fetch the complete documentation index at: https://to11.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Passthrough Routing

> How the to11 gateway proxies a request straight to a provider in L1 passthrough mode, and how that relates to bring-your-own-key credentials.

Passthrough is the default routing layer (L1). The gateway proxies your request straight to the upstream provider with no model remapping. It adds telemetry, security scanning, and cross-format translation along the way, but the routing itself is a direct proxy to the provider that serves the requested model.

## When passthrough applies

A request resolves to passthrough when the model it names does not match any [function](/docs/deploy/concepts/functions) or [route](/docs/deploy/concepts/routes). to11 looks up which connected provider serves that model and forwards the request to that provider.

If no connected provider serves the model either, the gateway returns a `404` (unknown model).

## How a customer uses passthrough

You reach passthrough in two ways:

* **Bring-your-own-key (BYOK) credential mode** — a dashboard setting. When you connect a provider in the **Project → AI Gateway → Providers** connect-provider drawer, you can choose a passthrough (BYOK) credential mode for it. In that mode the caller's own provider key is used to reach the upstream API. See [Connecting a provider](/docs/deploy/concepts/connect-provider-drawer).
* **The `provider::model` prefix** — set per request, not in the dashboard. Putting this prefix in the request's `model` field forces a direct proxy to a named provider, bypassing any route or function configured for that model:

```json theme={null}
{ "model": "openai::gpt-4o", "messages": [{ "role": "user", "content": "Hello" }] }
```

Even if a route or function is configured for `gpt-4o`, the prefix sends the request through passthrough to the `openai` provider.

The prefix chooses the routing layer — it is not a way around the environment's model list. A prefixed request for a model the environment does not serve returns a `404`, exactly like the unprefixed form.

## Which credential is used

A passthrough request can be served by a managed credential or by the caller's own provider key. The precedence default is **managed-credential-wins**: if a stored credential resolves for the request, the gateway uses it. The caller's own key — supplied in the `Authorization` header (or `x-api-key` for providers that use it) — is used when no managed credential resolves.

<Info>
  Two different keys travel on two different headers. `x-to11-authorization: Bearer <to11 key>` carries your to11 credential and authenticates the request to the gateway. `Authorization: Bearer <provider key>` (or `x-api-key`) carries an upstream provider key when you bring your own. Never put the to11 key in `Authorization`.
</Info>

## Coexistence with managed routing

Passthrough and managed routing live side by side in the same project. A model with a matching route or function uses managed routing; every other model falls through to passthrough. You do not configure passthrough explicitly — it is the behavior for any model that no route or function claims.

To confirm whether a given request went through passthrough or a managed route, open **Projects → Traces** in [Observe](/docs/observe/traces). Passthrough requests are recorded with a passthrough routing path; managed requests record the resolved route, strategy, and target.

## Next steps

<CardGroup cols={2}>
  <Card title="Direct routing" icon="key" href="/docs/deploy/routing/simple">
    Route a model to a single managed target.
  </Card>

  <Card title="Providers" icon="server" href="/docs/deploy/concepts/providers">
    Connect a provider and choose its credential mode.
  </Card>

  <Card title="Routing overview" icon="route" href="/docs/deploy/routing/overview">
    The three-layer model and top-down resolution.
  </Card>
</CardGroup>