In-Region Routing

​

Using In-Region Routing

https://eu.openrouter.ai
https://us.openrouter.ai

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({
  apiKey: '<OPENROUTER_API_KEY>',
  serverURL: 'https://eu.openrouter.ai/api/v1',
});

const completion = await openRouter.chat.send({
  chatRequest: {
    model: 'anthropic/claude-sonnet-5',
    messages: [{ role: 'user', content: 'Hello' }],
    stream: false,
  },
});

fetch('https://eu.openrouter.ai/api/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer <OPENROUTER_API_KEY>',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: 'anthropic/claude-sonnet-5',
    messages: [{ role: 'user', content: 'Hello' }],
  }),
});

import requests

headers = {
  'Authorization': 'Bearer <OPENROUTER_API_KEY>',
  'Content-Type': 'application/json',
}

response = requests.post('https://eu.openrouter.ai/api/v1/chat/completions', headers=headers, json={
  'model': 'anthropic/claude-sonnet-5',
  'messages': [{ 'role': 'user', 'content': 'Hello' }],
})

curl https://eu.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer <OPENROUTER_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

​

How Requests Are Routed

• 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

• Call /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 or US-eligible models on the models page with the In-Region Routing filter

​

Feature Availability

• Web search with external engines. The web search plugin 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 and 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, image generation, Fusion, and shell. Server tools that execute entirely in-region (such as tool search, apply patch, and datetime) remain available.
• Batch API. The Batch API 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.

​

Observability with In-Region Routing

• 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.

​

BYOK with In-Region Routing

• 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.

​

AWS Bedrock

• 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)

​

Google Vertex AI

• 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.

​

Why This Matters

​

Getting Started

• Upgrade to the Business plan from your organization settings (organization admins), or contact our enterprise team for Enterprise
• Review Sovereign AI for combining in-region routing with ZDR and data collection controls
• Configure BYOK keys with region-appropriate deployments as described above