{"slug": "a-new-privacy-savy-openrouter", "title": "A new privacy savy openrouter", "summary": "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.", "body_md": "**Account Type** in\n\n[Settings > Preferences](https://openrouter.ai/settings/preferences). For Enterprise,\n\n[contact our enterprise team](https://openrouter.ai/enterprise/form).\n\n## Using In-Region Routing\n\nSend API requests through the region-specific base URL:\n## How Requests Are Routed\n\nOn 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:\n- **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.\n- **Multi-model routers.** Router-type models (such as the Auto Router) are excluded from regional model lists.\n\n### Finding In-Region Models\n\nTo see which models are available for in-region routing:\n- 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\n- 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\n\n## Enforcing In-Region Routing with Guardrails\n\nSending 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\n[guardrail](https://openrouter.ai/docs/guides/features/guardrails). Each guardrail can specify\n\n`allowed_data_regions`, a list of the OpenRouter domains that requests governed by that guardrail must arrive through:\nA request that arrives through a domain not in the list is rejected with a \n\n**403 Forbidden** error before any inference or endpoint selection happens, so no prompt is ever processed outside the permitted regions. Leaving the setting unrestricted (\n\n`null`) accepts requests from any domain.\nEnforcement applies to every OpenRouter API surface, including chat completions, embeddings, rerank, image, audio, and video generation, server tools, the Batch API, and generation lookups.\nWhen 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`.\nTo 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\n\n**Data regions** or through the\n\n[Guardrails API](https://openrouter.ai/docs/api/api-reference/guardrails/create-a-guardrail).\n\nThe guardrail value for the EU is \n\n`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).\n## Feature Availability\n\nEverything 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.\n**Not available with in-region routing today:**\n\n- **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.\n- **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.\n- **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.\n- **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` .\n- **Multi-model routers** such as the Auto Router, as described above.\n\n[ZDR](https://openrouter.ai/docs/guides/features/zdr)) enforcement and\n\n[data collection controls](https://openrouter.ai/docs/guides/privacy/provider-logging)work normally with in-region routing and are commonly combined with it. See\n\n[Sovereign AI](https://openrouter.ai/docs/guides/features/sovereign-ai)for how these features compose.\n\n## Observability with In-Region Routing\n\n[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:\n\n- **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.\n- **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.\n- **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.\n\n[Settings > Observability](https://openrouter.ai/settings/observability)when adding or editing a destination. Separately, OpenRouter’s own\n\n[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.\n\n## BYOK with In-Region Routing\n\n[BYOK](https://openrouter.ai/docs/guides/overview/auth/byok)works with in-region routing, but there is an important boundary to understand:\n\n- **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.\n- **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.\n\n`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\n\n**Provider agreement → Data region** in your workspace BYOK settings. See\n\n[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.\n\n### AWS Bedrock\n\nHow OpenRouter chooses the Bedrock invocation region under in-region routing depends on your key type:\n- **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.\n- **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.\n- **Cross-region inference profiles:**`global.` inference profiles can process requests in any AWS region, so they are excluded from regional routing entirely.\n\n### Azure (AI Foundry and Azure OpenAI)\n\nAzure 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.\n**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.\n\n### Google Vertex AI\n\nVertex BYOK service account keys accept an optional`region` field that selects the Vertex location OpenRouter sends requests to. Under in-region routing:\n- **Set `region` to a location inside your data region** (e.g.`europe-west1` for the EU,`us-central1` for the US).\n- **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.\n- **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.\n\n### Baseten\n\nTo use Baseten under in-region routing, create a\n[regional Dedicated Deployment](https://docs.baseten.co/deployment/regional-deployments)in Baseten and add its URL as a\n\n[private model](https://openrouter.ai/docs/guides/routing/private-models)on OpenRouter. OpenRouter derives the region from the\n\n`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`.\nThe 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.\n### Why This Matters\n\nOpenRouter’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\n*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.\n\n## Getting Started\n\n- 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) .\n- Review [Sovereign AI](https://openrouter.ai/docs/guides/features/sovereign-ai) for combining in-region routing with ZDR and data collection controls\n- Configure [BYOK](https://openrouter.ai/docs/guides/overview/auth/byok) keys with region-appropriate deployments as described above", "url": "https://wpnews.pro/news/a-new-privacy-savy-openrouter", "canonical_source": "https://openrouter.ai/docs/guides/features/in-region-routing", "published_at": "2026-09-16 08:32:55+00:00", "updated_at": "2026-09-16 08:43:29.096467+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-policy", "ai-tools"], "entities": ["OpenRouter", "Bedrock", "Vertex", "Auto Router", "Guardrails API", "Models API"], "alternates": {"html": "https://wpnews.pro/news/a-new-privacy-savy-openrouter", "markdown": "https://wpnews.pro/news/a-new-privacy-savy-openrouter.md", "text": "https://wpnews.pro/news/a-new-privacy-savy-openrouter.txt", "jsonld": "https://wpnews.pro/news/a-new-privacy-savy-openrouter.jsonld"}}