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

# Targets

> What a target is in to11 — a model paired with a stored credential — and how targets feed managed routing.

A target pairs one model with one credential. Targets are the building blocks of managed routing: instead of your application supplying a provider key on every call, to11 uses a credential you have already stored and attaches it to requests that match a [route](/docs/deploy/concepts/routes).

## Why targets exist

In passthrough routing, every call carries its own upstream provider key. That works on a developer's machine, but it gets awkward across a shared project — staging, CI, or production — where one team manages provider relationships and budgets.

Targets move credential ownership to the project. You store provider credentials once under **Project → AI Gateway → Credentials**, then build routing rules whose targets reference those credentials. Calls to models covered by a managed route no longer need to carry a provider key; to11 supplies the stored one. Models that no route covers continue to work as passthrough.

## What a target carries

A target is two choices:

* **A model** — the upstream model the target sends to. It must be a model one of your connected providers exposes (see [Models](/docs/deploy/concepts/models)).
* **A credential** — the stored provider credential to11 uses for that model.

A target may also carry a **weight**, used only by the Weighted split strategy. Weight defaults to 1, so targets contribute equally unless you say otherwise. to11 figures out which connected provider serves the target's model from the model name; you do not pick the provider separately.

## Targets and routing strategies

You define a rule's targets when you build a [route](/docs/deploy/concepts/routes) in the dashboard's **AI Gateway → Routing** section. How many targets a route has goes together with its strategy:

* **One target** uses **Direct routing** — every matching request goes to that single model-and-credential pairing.
* **More than one target** uses a strategy that chooses between them: **Weighted split** (proportional to each target's weight) or **Fallback chain** (tried in order).

See [Routes](/docs/deploy/concepts/routes) for what each strategy does, and the routing how-tos for the build steps.

## Where targets sit

Targets sit between providers and routes:

* **Providers (L1)** define where an API lives and which models it serves.
* **Targets** bind a model to a specific stored credential, and optionally a weight.
* **Routes (L2)** group targets under a strategy and match them to a model name.

A route then matches incoming requests by model name (and endpoint kind) and selects one of its targets according to its strategy.

## Next steps

<CardGroup cols={2}>
  <Card title="Routes" icon="route" href="/docs/deploy/concepts/routes">
    How routes map model names to strategies across targets.
  </Card>

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

  <Card title="Routing overview" icon="shuffle" href="/docs/deploy/routing/overview">
    How passthrough and managed routing fit together.
  </Card>
</CardGroup>
