Data residency claims often hide a gap: a gateway may pin inference to a region, but decrypt and process your prompt elsewhere first. OpenRouter’s new US In-Region Routing closes that gap by keeping the entire request lifecycle inside the region you choose.
What changed
As of September 9, 2026, OpenRouter offers region-specific base URLs for the US and EU:
https://us.openrouter.ai/api/v1
https://eu.openrouter.ai/api/v1Requests sent to these endpoints are decrypted inside the region and routed only to providers running in that region. Your API key, request body, model IDs, provider preferences, fallbacks, and privacy settings all carry over unchanged. If no in-region provider serves a model, the request fails with a 404 instead of silently routing outside the region.
Why decryption location matters
OpenRouter distinguishes between two types of regional routing. Inference-only routing pins the provider’s compute to a region, but the gateway itself may decrypt and process your prompt elsewhere. End-to-end routing—what OpenRouter now offers—keeps data in-region for the full path, including server tools like web search. Tools that would send data outside the region are disabled rather than falling back to global infrastructure.
This distinction matters for compliance reviews. A US team using GPT-5.6, Claude Opus 5, or Gemini 3.6 Flash on a global endpoint can still fail a data residency review, because the request may be decrypted or processed outside the US even if the model lab is US-based.
Chinese open-weight models, in-region
Open-weight models from Chinese labs are a large share of token volume on OpenRouter, but procurement approval can be difficult for teams with residency requirements. In-Region Routing changes that calculus: when a US or EU provider hosts the model, requests go to that provider and the lab is not involved.
DeepSeek V4 Pro, Kimi K3, and GLM 5.2 are available for US routing because Baseten, Fireworks, and Azure serve them from US data centers. GLM 5.2 is also available in the EU, served from Mistral’s EU data centers. This lets teams get price and performance gains from open-weight models without violating data residency policies.
Enforcing the boundary
You can enforce In-Region Routing for a specific workspace, team, or API key using Guardrails. Set the guardrail’s allowed data region to one region, and OpenRouter rejects any covered request that arrives on another hostname. Configuration is available in settings or through the Management API.
The regional endpoints serve a subset of the global catalog under the same model IDs. To see the live list, call /api/v1/models through the regional domain or filter the models page by In-Region Routing. In-Region Routing is available on Business and Enterprise plans.
What to check in any gateway
When evaluating a gateway’s data residency claim, ask two questions: Where is the request decrypted and processed? And where do its tools run? OpenRouter’s approach answers both with a regional endpoint and a hard failure when no in-region provider exists. For teams already thinking about data loss prevention in AI products, this is a concrete control to add to your compliance checklist.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.