Summary: OpenRouter launched US and EU In-Region Routing on September 9, 2026, decrypting and processing requests inside the chosen region and routing only to providers there. It differs from inference-only routing by keeping the full path, including server tools, in-region and returning 404 when no local provider exists. Business and Enterprise plans can enforce the boundary through guardrails on workspaces, teams, or API keys.
A data residency claim can conceal a gap: a gateway may pin inference to a region while decrypting and processing your prompt somewhere else first. OpenRouter’s new US In-Region Routing closes that gap by holding the whole request lifecycle inside the region you pick.
What changed
Since September 9, 2026, OpenRouter publishes region-specific base URLs for the US and EU:
https://us.openrouter.ai/api/v1
https://eu.openrouter.ai/api/v1A request sent to either endpoint is decrypted inside that region and routed only to providers running there. Your API key, request body, model IDs, provider preferences, fallbacks, and privacy settings all carry over unchanged. When no in-region provider serves a model, the call comes back as a 404 rather than quietly routing outside the region.
Why decryption location matters
OpenRouter separates regional routing into two kinds. Inference-only routing pins a provider’s compute to a region, yet the gateway itself may still decrypt and process your prompt elsewhere. End-to-end routing—the kind OpenRouter now offers—holds data in-region across the entire path, server tools such as web search included. Any tool that would move data out of the region gets disabled instead of falling back to global infrastructure.
That difference is what compliance reviews turn on. A US team running GPT-5.6, Claude Opus 5, or Gemini 3.6 Flash through a global endpoint can still fail a data residency review: the request may be decrypted or processed outside the US even when the model’s lab is US-based.
Chinese open-weight models, in-region
Chinese labs’ open-weight models account for a large share of token volume on OpenRouter, yet approval can stall for teams bound by residency requirements. In-Region Routing shifts that math: when a US or EU provider hosts the model, the request goes to that provider and the lab has no part in it.
DeepSeek V4 Pro, Kimi K3, and GLM 5.2 support US routing because Baseten, Fireworks, and Azure serve them from US data centers. GLM 5.2 is also offered in the EU, served from Mistral’s EU data centers. Teams capture the price and performance gains of open-weight models without breaking their data residency policies.
Enforcing the boundary
Guardrails let you enforce In-Region Routing for a particular workspace, team, or API key. Set the guardrail’s allowed data region to a single region, and OpenRouter rejects every covered request that shows up on another hostname. You configure it in settings or through the Management API.
Those regional endpoints serve a subset of the global catalog under the same model IDs. For the live list, call /api/v1/models through the regional domain or filter the models page by In-Region Routing. In-Region Routing comes with Business and Enterprise plans.
What to check in any gateway
Two questions are worth asking of any gateway’s data residency claim: Where does the request get decrypted and processed? And where do its tools run? OpenRouter answers both with a regional endpoint and a hard failure when no in-region provider exists. If your team already works on data loss prevention in AI products, this is a concrete control for your compliance checklist.