How a call is routed

This page explains what happens to a model call between your app and the provider's answer. It is for developers who want to know which key a call runs on, what Mubit changes in it, and where it can go.

The path picks the provider

Mubit looks at the start of the path. Each prefix is one provider's own API:

After the prefix, the path is the provider's own and goes on as you sent it. Providers lists the prefixes, base URLs and key headers.

Mubit never picks a different provider from the model ID. A call on /openai/v1 that names a Claude model goes to the OpenAI API, or to your Neon AI Gateway if the rule below sends it there, and gets that service's answer.

Which provider key a call uses

Your app sends a Mubit key. Mubit takes it out and sends the call with a provider key from your project. For a call on /openai/v1, /anthropic or /gemini, Mubit uses the first of these that applies:

1. Your key for that provider. A call on /anthropic uses your Anthropic key.
2. Your Neon AI Gateway key. If the project has no key of its own for that provider, and has a Neon key, Mubit sends the call to your Neon branch's gateway. Connect with the Neon AI Gateway shows where each call lands.

A call under /compat/{service}/v1 uses your key for that service. It never goes to Neon.

If none applies, the call gets 403 provider_key_missing, and the message names the provider. Mubit tries no other provider and no other key: it never sends a call to a provider the path didn't name, and never sends one provider's key to another. An admin adds the missing key under Provider keys: see Provider keys.

What Mubit changes in the request

Mubit sends the body as you sent it, byte for byte, and keeps the model ID you wrote. It changes only the credentials and a few headers:

• The key. It takes out your Mubit key, and the key and token headers your SDK sets for its own key. It sends the provider key, or your Neon token, in the header that provider expects.
• Headers it drops. Cookies; forwarding headers such as forwarded, x-forwarded-for, x-real-ip and via; and every header that starts with x-middleware-.
• Headers it passes. Most others go as you sent them, such as anthropic-version, anthropic-beta and idempotency-key.
• Encoding. It asks the provider for an uncompressed answer, so the bytes your app reads are the bytes the provider sent.

Headers and request IDs lists them.

On a call to Neon, the path also changes: Mubit adds Neon's path for that API before the rest of your path.

What comes back

The provider's answer goes back to your app as it arrives, with its status, its headers and its errors. A redirect from a provider is not followed or passed on: the call gets 502 upstream_redirect. Streaming, timeouts and limits covers streams, time limits and retries.

Calls Mubit refuses before the provider

Mubit answers some calls itself, before any provider is asked: a missing or wrong key, a provider key or sign-in token sent in place of the Mubit key, a missing provider key, an unknown path, and an organization or admin path. Errors from Mubit lists each one. A call refused this way leaves no record.

When an adapter answers

If a task in your project has an adapter version in a partial rollout or live, Mubit may answer a call with the adapter instead of the provider. The call still names your model ID, and the answer carries it. Calls answered by an adapter says which calls this can apply to, and how to see it and turn it off.

Next

• Providers
• What Mubit records
• Keep your model IDs