Customer blocklist
Block or pin specific combinations of customers, providers, and models for your org
The customer blocklist gives org admins fine-grained control over what each of your customers is allowed to route through. Use it to enforce per-customer model restrictions, deny providers that aren’t approved for a customer’s data, or pin a customer to a specific allow-list of models for a pilot rollout.
Blocklist rules are evaluated on every request before routing runs. There are two rule types:
Each org can have up to 100 rules. Block rules always win over pin rules. If the same customer and model combination is both pinned-allowed and explicitly blocked, the request is blocked.
Blocklist rules run on the data-plane hot path. A change in the dashboard syncs to the data plane within seconds and takes effect on the next request.
Every rule combines three optional dimensions:
Block rule scope requirements: at least one of the three dimensions must be non-empty. A block rule with empty model and provider lists denies every model for the listed customers.
Pin rule scope requirements: customer_ids is required, and at least one of providers or models must be set. A pin rule says “for these customers, only these providers/models are allowed.”
Go to Configuration → Blocklists in the Merge Gateway dashboard to create, edit, and delete rules. Each rule has an optional human-readable reason field that shows up in the audit log for that rule’s create / update / delete events.
Use the reason field to record the ticket or compliance requirement that drove the rule. It makes audit reviews much faster.
A block rule that denies a specific customer from using any Anthropic model:
A pin rule that restricts a customer to two specific OpenAI models:
When a rule denies a request, Gateway returns HTTP 403 with a stable error body:
The code field tells you which dimension blocked the request:
Handle these the same way you’d handle any other 403. They’re stable and safe to match on programmatically.
Before. If a rule denies the request, Gateway returns 403 immediately without consulting the routing policy. This means you can’t route around a block by changing strategies.
The block wins. Gateway filters the policy’s candidate list to remove blocked models before scoring, so the model is never selected. If every candidate is blocked, the request fails with the standard “no eligible vendor” error from the routing policy.
No. Blocklist rules target customers (by customer_id), providers, and models. They don’t read the request’s source IP. If you need source-IP filtering, do it at your application layer before calling Gateway. For routing restrictions based on the vendor’s location, see Geo-location routing.
Yes. Blocklist rules are evaluated on every request regardless of whether the routing target is a managed or BYOK credential.
Org members with the Manage organization settings permission. Viewing the list requires View organization settings. All create, update, and delete actions are written to the org audit log.
Restrict routing to vendors in specific countries or regions for data-sovereignty
Every blocklist mutation is recorded. See who changed what, when, and from where.
Blocklist management requires the Manage organization settings permission. Review who holds it.