Targets

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.

​

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 a managed route, as route::<name>, no longer need to carry a provider key; to11 supplies the stored one. Calls that name a provider directly, as <provider-slug>::<model>, continue to work as passthrough.

​

What a target carries

A target is two choices:

• A model — the upstream model id the target sends to, on the provider you pick in the target’s Provider select. The Model field suggests the provider’s listed and catalog models and accepts any id you type. Enter the id as the provider names it, without a <provider-slug>:: prefix: the target names its provider separately, and the gateway sends the id upstream exactly as written. An id may itself contain ::, as an OpenAI fine-tuned model id such as ft:gpt-4o-mini-2024-07-18:my-org::abc123 does. The provider’s access policy still applies when the target is used: a target whose model is blocked, or not allowed, is skipped, and a request with no usable target left returns 404. When the provider denies by default and the model is not among its allowed models, the route builder warns you before you save.
• 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.

​

Targets and routing strategies

You define a rule’s targets when you build a route 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 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 may serve.
• Targets bind a model to a specific stored credential, and optionally a weight.
• Routes (L2) group targets under a strategy and give them a name your application calls.

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

​

Next steps