Route requests

By default, the gateway sends each request to the provider that matches its format. Routing rules override that. They let you send traffic to a specific provider or swap the model, without the caller changing anything.

​

How rules work

On the Routing rules page under Policies, add a rule. Each rule has three parts:

• Applies to: whose traffic it governs. One API key, a user, a group, keys with no group, or Unclaimed, the fallback that decides every request no more specific rule claims.
• Match: which of that traffic it covers.
  • Incoming format: openai or anthropic. Leave blank to match any.
  • Models: one or more exact model names. Leave blank to match any.
• Target: where matching requests go.
  • Provider: a connected provider to send to.
  • Model: an optional model to use instead of the one in the request.

​

Which rule wins

A request is forwarded to exactly one provider, so routing rules can’t stack the way usage limits and guardrails do. Two things decide the winner. First, the narrowest target wins. The gateway looks for a rule in this order and stops at the first group that has one:

1. A rule for the calling API key
2. A rule for its user
3. A rule for its group, or for having no group
4. The Unclaimed fallback

A key with both a group rule and a rule of its own is decided by its own. A group rule never overrides a key rule, however specific its match. Second, within that group, rules are evaluated top to bottom and the first match wins. Order them with the most specific match first. You can reorder rules on the page, and the table numbers each rule within its target so you can see the order at a glance. A request that reaches no matching rule at all passes through by format, as usual.

​

Example

For a group named research:

1. Match incoming format openai, models gpt-4o. Target provider foundry_openai, model my-gpt-4o-deployment.
2. Match incoming format anthropic. Target provider foundry_anthropic.

The first rule reroutes one specific model to an Azure deployment and renames it on the way. The second sends the group’s Anthropic traffic to Foundry. A key in research with a rule of its own ignores both.

​

Common uses

• Pin a provider: send all traffic to one upstream, whatever the caller targets.
• Swap a model: map a public model name onto your own deployment name.
• Mix providers: route some models to one provider and the rest to another.
• Carve out one team or app: give a group or a key its own upstream, and leave everyone else on the Unclaimed fallback.

Routing to a provider whose format differs from the caller’s triggers automatic translation. See Use any model from any SDK.