Do I need a separate OpenAI project or API key for each region?

No. Regional processing works from one API key belonging to a project with Global geography, which is the point of the change. OpenAI's Python example reuses a single client and a single key, overriding only the base URL per call, so a region no longer implies a separate project, key rotation or quota to manage.

What approvals does OpenAI require before a non-US region can be used?

OpenAI keeps its existing eligibility rules in place for regional processing. For any non-US region a customer must obtain approval for abuse monitoring controls and execute a Modified Retention amendment. The UAE region carries a further requirement: it needs its own separate approval on top of that, so access is not automatic.

Does every OpenAI model and endpoint support regional processing?

No. Only the endpoints and model snapshots explicitly marked as supporting regional processing in OpenAI's documentation tables accept a regional domain. The listed routes include /v1/chat/completions, /v1/responses and /v1/embeddings, and the supported model snapshots differ by region, so the tables have to be checked per region.

Can global and regional requests live in the same application?

Yes. Because regional processing at OpenAI is selected by hostname, one application can send some traffic to api.openai.com and route other traffic to a regional domain, using the same key. OpenAI's SDK example shows exactly this pattern: keep one client, change base_url on the calls that need a fixed region.

OpenAI · 2026-08-21 · major

OpenAI regional processing — pick an inference region per API request

OpenAI now lets a single API call choose where it runs. Swap api.openai.com for a regional domain such as eu.api.openai.com or jp.api.openai.com and that request is processed in that region. Ten regions are live.

OpenAI API documentation card for data controls and regional processing

One API key, ten regional domains — choose where each OpenAI request is processed.

Quick facts

Maker	OpenAI
What's new	Region chosen per request, not per project
Regions	US, EU, UK, Canada, Australia, Japan, India, Singapore, South Korea, UAE
How	Prefixed domain, e.g. eu.api.openai.com
Requirement	API key from a project with Global geography
Endpoints	/v1/chat/completions, /v1/responses, /v1/embeddings and other marked routes
Extra approval	Non-US regions need abuse-monitoring approval and a Modified Retention amendment

What is it?

Regional processing is now a per-request choice at OpenAI instead of a per-project setting. An API key from a project with Global geography can call a region-prefixed domain — eu.api.openai.com, jp.api.openai.com and eight others — and that one request is handled in the chosen region. OpenAI shipped it in the API changelog on 21 August 2026 and documented it in the data controls guide.

How does it work?

The routing decision rides entirely on the hostname. The request path, body and API key stay the same, so client code only changes its base URL; OpenAI's Python SDK example reuses one client and overrides base_url per call. Eligibility and data-retention rules are unchanged, and a regional domain is only accepted by the endpoints and model snapshots the docs mark as supported.

Why does it matter?

Teams under data-residency rules previously had to split traffic across separate region-locked OpenAI projects, each with its own key, quota and deployment. Choosing the region at call time lets one codebase serve an EU customer and a US customer from the same key, which turns residency into a routing decision instead of a fork of the stack.

Who is it for?

enterprise and compliance-bound API teams

Frequently asked questions

Do I need a separate OpenAI project or API key for each region?: No. Regional processing works from one API key belonging to a project with Global geography, which is the point of the change. OpenAI's Python example reuses a single client and a single key, overriding only the base URL per call, so a region no longer implies a separate project, key rotation or quota to manage.
What approvals does OpenAI require before a non-US region can be used?: OpenAI keeps its existing eligibility rules in place for regional processing. For any non-US region a customer must obtain approval for abuse monitoring controls and execute a Modified Retention amendment. The UAE region carries a further requirement: it needs its own separate approval on top of that, so access is not automatic.
Does every OpenAI model and endpoint support regional processing?: No. Only the endpoints and model snapshots explicitly marked as supporting regional processing in OpenAI's documentation tables accept a regional domain. The listed routes include /v1/chat/completions, /v1/responses and /v1/embeddings, and the supported model snapshots differ by region, so the tables have to be checked per region.
Can global and regional requests live in the same application?: Yes. Because regional processing at OpenAI is selected by hostname, one application can send some traffic to api.openai.com and route other traffic to a regional domain, using the same key. OpenAI's SDK example shows exactly this pattern: keep one client, change base_url on the calls that need a fixed region.

Try it

base_url="https://eu.api.openai.com/v1"