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

# Direct Routing

> Route a model to a single managed target so callers can use it without supplying their own provider key.

Direct routing (the `single` strategy) sends all traffic for a model to one target. Once it is in place, callers send requests by model name and to11 uses the stored credential to reach the provider — the caller does not supply a provider key. Use it when one provider and one credential are all you need for a model.

## Before you start

* A provider connected under **Project → AI Gateway → Providers**, with the model you want in its model list. See [Connecting a provider](/docs/deploy/concepts/connect-provider-drawer).
* A stored credential for that provider, set up under **Credentials**.

## Create a Direct routing rule

1. Open **Project → AI Gateway → Routing**.
2. In the routing list, start a new rule with the create-rule flow.
3. Choose the **Direct routing** strategy.
4. Set the model the rule applies to (for example `gpt-4o`).
5. Choose the target: the provider and the stored credential to use for this model.
6. Save the rule.

From now on, requests for that model resolve to this route, and to11 injects the stored credential. Models without a matching route still fall through to [passthrough](/docs/deploy/routing/passthrough).

## Send a request

Once the rule is live, call the model by name. The caller needs only its to11 credential — no provider key:

```bash theme={null}
curl https://gw.to11.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-to11-authorization: Bearer $TO11_API_KEY" \
  -H "x-to11-project-id: $TO11_PROJECT_ID" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello"}]
  }'
```

to11 resolves the route, uses the stored credential, and proxies the request to the provider. You receive a standard chat completion response.

<Note>
  The to11 credential goes in `x-to11-authorization`. `Authorization` (or `x-api-key`) is reserved for an upstream provider key when you bring your own — it is not used for a managed route.
</Note>

## Managed and passthrough together

A project can mix the two. Each Direct routing rule covers one model, and every model without a rule falls through to passthrough, where the caller supplies a provider key. For example, with a separate Direct routing rule on `gpt-4o` and on `claude-sonnet-4-6`, but none on `gpt-4o-mini`:

| Model               | Routing mode             | Caller supplies a provider key? |
| ------------------- | ------------------------ | ------------------------------- |
| `gpt-4o`            | Managed (Direct routing) | No                              |
| `claude-sonnet-4-6` | Managed (Direct routing) | No                              |
| `gpt-4o-mini`       | Passthrough              | Yes                             |

To confirm how a given request resolved — managed route or passthrough, and which target served it — open **Projects → Traces** in [Observe](/docs/observe/traces).

## Next steps

<CardGroup cols={2}>
  <Card title="Weighted split" icon="scale-balanced" href="/docs/deploy/routing/weighted">
    Split traffic across multiple targets by weight.
  </Card>

  <Card title="Fallback chain" icon="rotate" href="/docs/deploy/routing/fallback">
    Fail over to the next target on error.
  </Card>

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