> ## Documentation Index
> Fetch the complete documentation index at: https://openlayer.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Route requests

> Send traffic to a specific provider or swap the model, with routing rules

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.

<img width="700" style={{ borderRadius: "0.5rem" }} src="https://mintcdn.com/openlayer-docs/a2_1CfDP3O8kf5P1/images/gateway/routing_rules.png?fit=max&auto=format&n=a2_1CfDP3O8kf5P1&q=85&s=6ba10846acabe4eb3f2df8a34e2f09c6" alt="Routing rules listed by target, each showing what it matches and which provider it routes to" data-path="images/gateway/routing_rules.png" />

## 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](/docs/gateway/use-any-model).

<Note>
  Routing decides where a request goes. Which models a key may ask for in the
  first place is [model access](/docs/gateway/model-access), enforced before routing
  on the name the client sent. A routing rewrite isn't checked against it.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.