Geo-location routing

Geo-location routing restricts which vendors Merge Gateway can route to based on where each vendor’s infrastructure sits. Use it to enforce EU-only routing for GDPR-covered traffic, exclude CN-hosted vendors, or pin to vendors in specific countries for customer-contract reasons.

How vendor regions are tagged

Every vendor in Gateway’s catalog has two geo attributes set by Merge:

country_code - ISO-3166 alpha-2 (US, CA, FR, CN, …).
geo_region - a coarse bucket: NA, EU, APAC, or CN.

Both attributes are matched against your org’s region tokens. The current vendor → country/region mapping is published on Provider terms.

Allow and deny lists

Two region lists are configured per org and apply across all projects, customers, and API keys:

List	Effect
Allowed regions	Only vendors that match a token in this list are routable. Vendors with no geo tags are excluded.
Ignored regions	Vendors that match a token in this list are excluded. Vendors with no geo tags are kept.

A token matches a vendor when it equals the vendor’s country_code or the vendor’s geo_region. The two lists cannot overlap - Gateway rejects configurations that put the same token in both.

Configuration example

To require EU-only routing:

EU only

1 {
2   "vendor_restrictions": {
3     "allowed_regions": ["EU"],
4     "ignored_regions": [],
5     "allowed_vendors": [],
6     "ignored_vendors": []
7   }
8 }

To exclude CN-hosted vendors but allow everything else:

Exclude CN

1 {
2   "vendor_restrictions": {
3     "allowed_regions": [],
4     "ignored_regions": ["CN"],
5     "allowed_vendors": [],
6     "ignored_vendors": []
7   }
8 }

Vendor-level allow / deny lists

vendor_restrictions also supports per-vendor allowed_vendors and ignored_vendors lists for cases where region buckets are too coarse. Vendor slugs must match an active vendor - Gateway validates the list on save and rejects unknown slugs.

Use vendor-level lists when you need finer control than a region bucket gives you - for example, “allow EU vendors but exclude one specific EU vendor whose new sub-processor list hasn’t been approved yet.”

Interaction with other features

Geo-location routing runs before routing policies and after the customer blocklist check:

Customer blocklist rules deny or pin per-customer.
Geo filters narrow the candidate vendor pool to those that match your region lists.
The routing policy picks among the remaining candidates.

A request must pass every stage to reach a vendor. If the geo filter empties the candidate pool, the request fails with the standard “no eligible vendor” error from the routing policy.

Geo controls target the vendor’s location, not the caller’s. They restrict where data is sent, not where requests originate.

Who can configure geo controls

Geo-location settings live on the org-settings resource. Read access requires the view_org_settings permission; modifying the lists requires manage_org_settings. Every change is recorded in the audit trail as an ORG_SETTINGS_UPDATED event.

FAQ

What happens to vendors without country / region tags?

For allowed_regions, untagged vendors are excluded (fail-closed). For ignored_regions, untagged vendors are kept (fail-open). This means switching from an open routing setup to a strict allow-list is safe - anything Gateway doesn’t recognize as in-region is dropped, not silently allowed.

Can I combine allowed_regions and ignored_regions?

Yes, but they can’t contain overlapping tokens. Gateway rejects the save if the same token (e.g., "CN") appears in both. Most orgs use one or the other.

Does the geo filter affect BYOK traffic?

Yes. BYOK routes still go through the vendor’s region tag, so they’re filtered the same way as managed credentials.

What's the difference between this and the customer blocklist?

The customer blocklist targets customer_id + provider + model combinations. Geo-location routing targets the vendor’s location and applies to every request from the org, regardless of customer. They run independently - a request must pass both.

Where do I see each vendor's country / region?

On Provider terms. The table is the source of truth for what tokens match which vendor.

Next steps

Customer blocklist

Per-customer block and pin rules across providers and models.

Provider terms

Every vendor’s country, region, and terms of service in one table.

Zero data retention

Restrict routing to vendors with zero data retention agreements.