Skip to main content
A provider is an LLM API that to11 knows how to reach on your behalf — OpenAI, Anthropic, Google Gemini, and so on. Connecting a provider tells to11 where the API lives, how to authenticate to it, and which of its models it may serve. Every request that passes through the gateway ultimately resolves to one connected provider. You connect and manage providers in the dashboard, under Project → AI Gateway → Providers. There is nothing to install and no configuration file to edit; to11 operates the gateway, and you configure it through the dashboard.

​
What a connected provider holds

Each provider you connect carries four things:
  • A base URL — where to11 sends requests for that API. The provider catalog fills this in for known providers; some (for example self-hosted or cloud-deployment providers) ask you for the parts that are specific to your account.
  • Authentication — the credential to11 uses to call the upstream API, and how it is presented (a bearer token, a provider-specific header, or a URL parameter, depending on the provider). You supply the credential when you connect the provider; to11 stores it and uses the form the provider expects.
  • A routing identifier — the provider slug your requests use to name it, as <slug>::<model>. See Naming the provider in a request.
  • An access policy — Allow by default serves every model except blocked ones (the default); Deny by default serves only the models you allow. See Models.
The dashboard catalog covers the common providers — openai, anthropic, gemini, vertex, bedrock, mistral, groq, and more. Pick the one you want from the Providers list and connect it through the drawer.
to11 stores and presents the upstream credential for you. When you call the gateway, your application carries its to11 credential in the x-to11-authorization header. Do not put the to11 key in Authorization — Authorization (or x-api-key) is reserved for an upstream provider key when you bring your own.

​
Connecting a provider

Providers are connected from the Project → AI Gateway → Providers section using the connect-provider drawer, which validates the credential and discovers the available models before saving. For the step-by-step flow, see Connect a provider.

​
How providers relate to routing

Providers are the foundation that the routing layers build on. to11 resolves requests across three layers (see the Routing overview):
  • Passthrough (L1) — the request names the provider, as <provider-slug>::<model> or with the x-to11-provider-id header, and to11 forwards it there. No routing rule is required.
  • Managed routing (L2) — a route, called as route::<name>, applies a strategy across a set of targets; each target pairs a model with a stored credential. The provider supplies the base URL and the credential.
  • Function dispatch (L3) — a function, called as function::<name>, names a task and resolves to a route or a model on a connected provider.
Every request names its provider or route explicitly; the gateway does not search your providers for a model. A model the named provider does not serve in the request’s environment returns a 404, and a bare model name with no provider returns a 400.

​
Next steps

Connecting a provider

Walk through the connect-provider drawer step by step.

Models

Which models a connected provider exposes.

Targets

Pairing a model with a stored credential for managed routing.

Routing overview

How passthrough, managed routing, and functions fit together.