Connect a provider

INFRO routes your requests through your own provider accounts. You connect a credential you already hold — OpenAI, Anthropic, Google, Azure OpenAI, Bedrock, Vertex, an aggregator, or any OpenAI-compatible endpoint — and your provider bills you directly for what those requests cost, at whatever rates you have negotiated with them. INFRO takes 0% of it.

Connecting one

1. Open Providers in the console and choose the provider kind. The kind decides the wire protocol, which models it can serve, and what configuration it needs beyond a key — Azure OpenAI wants a resource and a deployment, Bedrock wants a region.
2. Give the connection a name you will recognise. Two accounts with the same provider — production and staging, or two business units — need telling apart on every screen that names one.
3. Paste the credential. It is sent once, sealed at the gateway, and never returned by any endpoint.
4. Validate it. INFRO calls your provider with the connection's real base URL and auth and reports what came back, so a key with a typo in it is caught here rather than by your first production request.

How the credential is stored

• Encrypted before it is stored, with AES-256-GCM under a key held as a Worker secret rather than in the database. A database dump on its own opens nothing.
• Bound to your organization and that one connection. The binding is part of the encryption, so a sealed credential copied into another organization's row — or even into your own second connection — fails to decrypt rather than silently authenticating as the wrong account.
• Never returned. No endpoint, console screen, export or support tool will show you the value again. What you can see is the last four characters and when it was set. There is no reveal, for anyone, including us: a reveal turns one compromised session into every provider credential an organization holds.
• Replaceable at any time. Replacing a credential takes effect on the next request. Replacing it here does not revoke the old one at your provider — do that too.

How a request finds a connection

In this order, and the first step that produces a candidate wins:

1. A route. If model matches one of your route slugs, that route's targets are used in its own order.
2. A model. If model is a catalog id like anthropic/claude-sonnet-5, or a bare provider model id, every enabled and healthy connection whose kind serves that vendor is tried in the order you created them.
3. Nothing. 503 no_provider_connected, naming what to connect.

Two connections for the same vendor is the simplest useful reliability setup and needs no configuration at all: the second is tried when the first fails, and the request's trace names which one served it.

Environments

A connection can be scoped to an environment, and an API key can name one. Matching is deliberately fail-closed in both directions: a key that names an environment reaches connections in that environment and unscoped ones, and a key that names none reaches only unscoped connections.

Health and ejection

• Consecutive failures eject a connection from rotation for a cool-off rather than letting it keep taking traffic. It re-enters on its own; nobody has to notice and re-enable it.
• While a connection is ejected, requests go to the next one that can serve the model — another of your connections for that vendor, or the next target on the route.
• An ejected connection is not a missing connection. The console says so, and the 503 for a model whose only connection is ejected does not tell you to connect a provider you already connected.
• Disabling a connection is a separate act from clearing its credential, and neither implies the other. Doing one as a side effect of the other surprises somebody mid-rotation.

What your provider sees

Your request, under your credential, on your account — the same request they would have received had your application called them directly. INFRO does not add an account identifier of yours, does not rewrite the model id, and does not substitute a different model. Because the account is yours, your provider's own terms, data-handling commitments and retention settings apply to it, and they are not INFRO subprocessors: see subprocessors.

Model mapping

A connection can carry a map from a catalog slug to the id that connection calls the model by. Azure OpenAI addresses a deployment name rather than a model name, a self-hosted server may name a model whatever it likes, and an aggregator may prefix it. Set the mapping once on the connection and your application keeps sending the catalog id.