Providers

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 you want to use. 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 three 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 model list — the models you want this provider to expose. When you connect a provider, to11 discovers the models the API offers; you choose which ones are available to your project. 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.

​

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) — to11 looks up which connected provider serves a model and forwards the request. No routing rule is required.
• Managed routing (L2) — a route maps a model name to a strategy and 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 names a task and resolves to a route or a model. Model names still resolve through the connected providers.

Resolution is top-down: a function match wins first, then a route match, then a direct provider match. A model that no connected provider serves is unknown to the gateway and returns a 404.

​

Next steps