A new privacy savy openrouter

OpenRouter introduced in-region routing that filters API requests to provider endpoints physically located in a specified region, failing closed with an error rather than falling back to an out-of-region endpoint. Requests to regional domains such as eu.openrouter.ai can be enforced through guardrails using the allowed_data_regions setting, where a request arriving through a non-permitted domain is rejected with a 403 Forbidden error before any inference or endpoint selection occurs. Global and cross-region deployments, including Bedrock global cross-region inference profiles and Vertex global locations, plus router-type models such as the Auto Router, are excluded from regional routing.

Account Type in Settings Preferences https://openrouter.ai/settings/preferences . For Enterprise, contact our enterprise team https://openrouter.ai/enterprise/form . Using In-Region Routing Send API requests through the region-specific base URL: How Requests Are Routed On a regional domain, OpenRouter filters the candidate endpoints for your request down to those whose provider infrastructure is located in that region. If OpenRouter has not onboarded an endpoint for the requested model to that region, the request fails with an error rather than falling back to an out-of-region endpoint. A provider might serve the model from infrastructure in the region, but the endpoint is only eligible once OpenRouter has onboarded it for EU or US routing. See Finding In-Region Models for the current list. In-region routing fails closed: OpenRouter never silently routes a regional request outside the region. Two categories of endpoints are always excluded from regional routing even if the model is otherwise available: - Global / cross-region deployments. Provider deployments that can process requests in any region for example, Bedrock global. cross-region inference profiles or Vertex global locations do not guarantee residency and are not eligible. - Multi-model routers. Router-type models such as the Auto Router are excluded from regional model lists. Finding In-Region Models To see which models are available for in-region routing: - Call /api/v1/models https://eu.openrouter.ai/api/v1/models on a regional domain to get the full list programmatically, or pass a region query parameter eu or us on the main domain - Browse EU-eligible models https://openrouter.ai/models?region=eu or US-eligible models https://openrouter.ai/models?region=us on the models page with the In-Region Routing filter Enforcing In-Region Routing with Guardrails Sending requests to a regional base URL is a per-request choice. To guarantee that traffic for a key, member, or an entire workspace can only enter OpenRouter through a specific region, restrict the allowed data regions in a guardrail https://openrouter.ai/docs/guides/features/guardrails . Each guardrail can specify allowed data regions , a list of the OpenRouter domains that requests governed by that guardrail must arrive through: A request that arrives through a domain not in the list is rejected with a 403 Forbidden error before any inference or endpoint selection happens, so no prompt is ever processed outside the permitted regions. Leaving the setting unrestricted null accepts requests from any domain. Enforcement applies to every OpenRouter API surface, including chat completions, embeddings, rerank, image, audio, and video generation, server tools, the Batch API, and generation lookups. When more than one guardrail governs a request the workspace default guardrail, the member’s guardrail, and the API key’s guardrail , the effective set of regions is the intersection of every guardrail that sets one, so a lower-level guardrail can only narrow the regions permitted above it. For example, if the workspace default guardrail allows europe and us and an API key guardrail allows only europe , requests with that key must arrive through https://eu.openrouter.ai . To enforce EU residency for a whole workspace, set allowed data regions to "europe" on the workspace default guardrail https://openrouter.ai/docs/guides/features/guardrails updating-the-workspace-default-guardrail-via-api . This can be configured in the guardrail editor under Data regions or through the Guardrails API https://openrouter.ai/docs/api/api-reference/guardrails/create-a-guardrail . The guardrail value for the EU is europe , while the Models API https://openrouter.ai/docs/api/api-reference/models/list-all-models-and-their-properties region filter takes region=eu . The two are not interchangeable. global in the list keeps https://openrouter.ai open . Feature Availability Everything on a regional domain must uphold the same residency guarantee as inference itself. Features whose infrastructure or third-party vendors process data outside your region are therefore unavailable on regional domains today, and requests that use them return an error instead of silently processing data out of region. Not available with in-region routing today: - Web search with external engines. The web search plugin https://openrouter.ai/docs/guides/features/plugins/web-search engines Exa, Perplexity, Parallel, and Firecrawl are external vendors that process your queries outside your data region, so they are rejected on regional domains. Native provider web search still works : search executed by the model provider itself e.g. engine: "native" on a model that supports it stays with the region-filtered endpoint and remains available. - Web search and web fetch server tools. The web search https://openrouter.ai/docs/guides/features/server-tools/web-search and web fetch https://openrouter.ai/docs/guides/features/server-tools/web-fetch server tools are backed by the same out-of-region search and fetch vendors, so they are not available on regional domains. - Other server tools with out-of-region infrastructure , including files https://openrouter.ai/docs/guides/features/server-tools/files , image generation https://openrouter.ai/docs/guides/features/server-tools/image-generation , Fusion https://openrouter.ai/docs/guides/features/server-tools/fusion , and shell https://openrouter.ai/docs/guides/features/server-tools/shell . Server tools that execute entirely in-region such as tool search https://openrouter.ai/docs/guides/features/server-tools/tool-search , apply patch https://openrouter.ai/docs/guides/features/server-tools/apply-patch , and datetime https://openrouter.ai/docs/guides/features/server-tools/datetime remain available. - Batch API. The Batch API https://openrouter.ai/docs/batch-quickstart currently runs on US-based storage and queueing infrastructure and does not yet support regional data residency. Submit batch requests through the global endpoint at openrouter.ai . - Multi-model routers such as the Auto Router, as described above. ZDR https://openrouter.ai/docs/guides/features/zdr enforcement and data collection controls https://openrouter.ai/docs/guides/privacy/provider-logging work normally with in-region routing and are commonly combined with it. See Sovereign AI https://openrouter.ai/docs/guides/features/sovereign-ai for how these features compose. Observability with In-Region Routing Broadcast https://openrouter.ai/docs/guides/features/broadcast supports in-region routing. Every broadcast destination is configured with the data regions it receives traces from global, EU, or US , and a trace from a regional request is only delivered to destinations configured for that region. Regional broadcast delivery upholds the same data boundary as inference: - Traces are sent from within the data boundary. EU and US traces are delivered to your destination directly from infrastructure inside the region, and regional trace data is never persisted to queueing infrastructure outside the region. - Delivery is best-effort. Because regional traces are handled in memory only and never queued out of region, a failed delivery to a destination is not retried through the global retry queue the way global traffic is. - You control where the destination lives. OpenRouter sends the trace from inside the data boundary, but the receiving endpoint is yours. If you need end-to-end residency for observability data, host the destination e.g. your OpenTelemetry collector, Langfuse instance, or S3 bucket inside the selected data boundary. Settings Observability https://openrouter.ai/settings/observability when adding or editing a destination. Separately, OpenRouter’s own input/output logging https://openrouter.ai/docs/guides/features/input-output-logging is currently skipped for all requests through the regional endpoints, even when the feature is enabled. Requests work as normal; prompt and completion logging is simply not performed. BYOK with In-Region Routing BYOK https://openrouter.ai/docs/guides/overview/auth/byok works with in-region routing, but there is an important boundary to understand: - OpenRouter controls which shared endpoints are eligible. On a regional domain, OpenRouter only routes to shared provider endpoints whose infrastructure is located in that region. BYOK endpoints are not filtered this way: they are added for the provider your key belongs to, and OpenRouter sends the request to the resource your key is configured for. - You control where your own deployment runs. For hyperscaler providers AWS Bedrock, Azure, Google Vertex AI , your BYOK key authenticates against cloud resources in your account. OpenRouter cannot move or reconfigure those resources. If your deployment is provisioned in a region outside your data region, requests to it would leave the region. eu.openrouter.ai or us.openrouter.ai does not by itself regionalize your cloud deployments. When you combine BYOK with in-region routing, you must ensure your hyperscaler deployments are provisioned in the matching region. The provider-specific behavior is below. Your key is only used for a model when the provider’s shared endpoint for that model is itself eligible for the region. When that shared endpoint is outside your data region but your own account with the provider processes requests inside it, declare the region on the key under Provider agreement → Data region in your workspace BYOK settings. See Declaring a Data Region on a Key https://openrouter.ai/docs/guides/overview/auth/byok declaring-a-data-region-on-a-key for the options and the cases where the declaration is not honored. AWS Bedrock How OpenRouter chooses the Bedrock invocation region under in-region routing depends on your key type: - AWS credentials JSON with a region field : If your configured region is inside your data region e.g. eu-west-1 on the EU domain, us-east-1 on the US domain , OpenRouter uses it. If your configured region is outside your data region, or no region is set, OpenRouter does not honor it; it instead invokes Bedrock in a default in-region location eu-west-1 for the EU, us-east-1 for the US . Your AWS credentials must therefore have Bedrock access and model access enabled in that region, or requests will fail. - Bedrock API keys: These are tied to a single AWS region at creation time and cannot be redirected. Create the key in a region inside your data region. - Cross-region inference profiles: global. inference profiles can process requests in any AWS region, so they are excluded from regional routing entirely. Azure AI Foundry and Azure OpenAI Azure BYOK configurations point at a specific resource you created resource name for Foundry configs, or a full endpoint url for per-deployment configs . The geographic region of that resource was fixed when you created it in the Azure portal, and OpenRouter routes to the resource exactly as configured. You must create your Azure resource in a region within your data region e.g. an EU Azure region such as Sweden Central or West Europe for the EU domain . OpenRouter cannot verify or change where your Azure resource is deployed; a US-deployed Azure resource used from the EU domain would process your prompts in the US. Also review Azure’s own data-processing settings: some Azure OpenAI features such as global deployment types process data outside the resource’s region, so use regional not global deployment types for residency-sensitive workloads. Google Vertex AI Vertex BYOK service account keys accept an optional region field that selects the Vertex location OpenRouter sends requests to. Under in-region routing: - Set region to a location inside your data region e.g. europe-west1 for the EU, us-central1 for the US . - For most Vertex models, OpenRouter enforces this : a key region outside your data region is rejected with an error, and an unset or "global" region resolves to a default location inside your data region instead of Google’s global endpoint. Make sure your project has model access and quota in that location. - Exceptions : models served through Vertex’s OpenAI-compatible endpoint which includes non-OpenAI models such as Llama and DeepSeek and models served through the Vertex Interactions API use the key’s configured region directly, defaulting to global when unset, without enforcement against your data region. Because you cannot always tell from the model which path serves it, always set an explicit in-region location on your key and never use "global" , since the global location lets Google process the request in any region. Baseten To use Baseten under in-region routing, create a regional Dedicated Deployment https://docs.baseten.co/deployment/regional-deployments in Baseten and add its URL as a private model https://openrouter.ai/docs/guides/routing/private-models on OpenRouter. OpenRouter derives the region from the model-{model id}-region-{us|eu}.api.baseten.co hostname: a region-eu deployment is eligible on eu.openrouter.ai , a region-us deployment on us.openrouter.ai . The region is fixed per deployment, so changing the URL on OpenRouter re-derives it. Shared Model APIs, non-regional dedicated hosts, and regional environments are served on the global domain only. Why This Matters OpenRouter’s in-region guarantee covers everything OpenRouter controls: where your request is decrypted, which provider endpoints it is routed to, and where responses are processed. For BYOK on hyperscalers, the final leg of the request runs on infrastructure in your cloud account, so the residency of that leg is determined by how you provisioned it. A correctly regionalized deployment plus a regional OpenRouter domain gives you end-to-end residency; a misconfigured deployment silently breaks it on the leg you control, which is why verifying your deployment regions is essential. Getting Started - Organization admins can upgrade to the Business plan under Account Type in Settings Preferences https://openrouter.ai/settings/preferences . For Enterprise, contact our enterprise team https://openrouter.ai/enterprise/form . - Review Sovereign AI https://openrouter.ai/docs/guides/features/sovereign-ai for combining in-region routing with ZDR and data collection controls - Configure BYOK https://openrouter.ai/docs/guides/overview/auth/byok keys with region-appropriate deployments as described above