Geo-location routing
Geo-location routing
Restrict routing to vendors in specific countries or regions for data-sovereignty
Geo-location routing
Restrict routing to vendors in specific countries or regions for data-sovereignty
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.
Every vendor in Gateway’s catalog has two geo attributes set by Merge:
country_code: ISO-3166 alpha-2 (US, CA, FR, CN, and so on)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.
Two region lists are configured per org and apply across all projects, customers, and API keys:
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.
To require EU-only routing:
To exclude CN-hosted vendors but allow everything else:
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.”
Geo-location routing runs before routing policies and after the customer blocklist check:
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.
Geo-location settings live on the org-settings resource. Read access requires the View organization settings permission. Modifying the lists requires Manage organization settings. Every change is recorded in the audit trail as an ORG_SETTINGS_UPDATED event.
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.
Yes. BYOK routes still go through the vendor’s region tag, so they’re filtered the same way as managed credentials.
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, and a request must pass both.
On Provider terms. The table is the source of truth for what tokens match which vendor.