Vendor access

Some model vendors on Merge Gateway are access-gated: your organization needs access enabled before it can route to their models. Gating applies to a model’s author, so it covers every hosting path at once, including a vendor’s own API and its models served through Amazon Bedrock.

Which vendors are gated

Every other vendor is ungated. This table is the full list; if a vendor is not on it, it needs no access request.

Who has access

If you are on Free or Pro and your organization was created on or after a vendor’s cutoff, contact support to request access.

Gating follows the model’s author, not its host

A gated vendor covers every model whose canonical id begins with that vendor’s slug, regardless of which vendor executes the request. With Anthropic gated, both of these are gated:

• anthropic/claude-sonnet-4-5 served by Anthropic
• the same model served by Bedrock, where the vendor’s own name for it is anthropic.claude-sonnet-4-5-20250929-v1:0

Models by other authors on the same host are not gated. meta/llama-3.1-70b and Amazon’s own Nova models route normally on Bedrock whether or not you have Anthropic access.

This is deliberately different from your organization’s own vendor restrictions, which filter on the execution host.

You can see which models are gated for your organization in the dashboard’s Model Explorer, where they are labelled Requires access, or from GET /v1/models, where each entry carries:

1
{
2
  "model": "anthropic/claude-sonnet-4-5",
3
  "access_required": true,
4
  "access_reason": "vendor_access_required"
5
}

Gated models are still listed, so you can see what is available to request. access_required is false on every model you can already call.

How requests behave without access

Asking for a gated vendor’s model directly

A request that names the model is refused with 403:

1
{
2
  "error": {
3
    "type": "blocked_by_policy",
4
    "code": "vendor_access_required",
5
    "message": "Anthropic models are not enabled for this organization. Contact [email protected], or use the in-app chat, to request access."
6
  }
7
}

Branch on code, not on the message text. The message names the vendor; the code is the same for every gated vendor. See Errors.

These refusals are recorded as blocked requests rather than errors, so they do not count toward your error rate in Logs.

Routing policies and default_routing

A gated vendor’s targets are skipped, not fatal. A request under a routing policy or default_routing whose best candidate belongs to a gated vendor falls through to the next permitted vendor and succeeds normally.

The one case that fails is a policy where every target belongs to a gated vendor. There is nothing left to route to, so the request returns the same 403.

Saving configuration

Because a saved target you cannot route to would never be used, Gateway rejects it at write time rather than letting it fail silently on every request. Without access to a vendor you cannot:

• add one of its models to a routing policy, including a project-scoped policy
• point a model alias at one of its models
• set one of its models as a candidate in a model migration

These return 400 with a message naming the model, the vendor, and how to request access.

Setting a gated vendor’s model as a migration baseline is always allowed. If your access was revoked, migrating off that vendor is exactly what you need to be able to do.

Requesting access

Reach out through the in-app chat in the dashboard, or email [email protected]. Tell us which vendor and models you need and roughly what volume you expect.

Once access is granted it applies to your whole organization and takes effect within a few minutes, with no change needed on your side. Requests that were returning 403 start succeeding, the models stop being labelled Requires access, and you can add them to routing policies.

Next steps