OpenAI adds per-request regional processing selection to the API
OpenAI now lets API customers pin an individual request to a specific processing region, using a prefixed domain on an account with Global-geography data settings — giving developers request-level control over where their data is processed without restructuring their entire integration.
What's new
The change, added to the OpenAI API changelog on August 21, 2026, lets a customer select regional processing for a single request by calling a prefixed domain with an API key from a project configured for Global geography. Existing eligibility rules, data-retention controls, endpoint availability, and model-support requirements all still apply — this is a routing option layered on top of the existing data-residency framework, not a new tier of service. OpenAI points developers to its "Data residency" guide for the mechanics of selecting a region per request.
Previously, a project's processing region was effectively fixed by its geography setting; any customer needing different regions for different workloads had to either accept a single default region or run separate projects. Per-request selection removes that constraint for accounts that qualify.
Context
OpenAI has been building out data-residency options over the past year as more regulated and enterprise customers — banks, healthcare systems, government agencies — adopt the API for workloads with strict data-locality requirements under regimes like GDPR or sector-specific rules. Regional processing controls, along with zero-data-retention options and enterprise compliance tooling, are part of that broader push to make the API viable for customers who previously had to rule it out on jurisdictional grounds.
This also lands the same week OpenAI shipped a Prompt Caching dashboard and cut GPT-5.6 Sol pricing, part of a steady cadence of platform-level API refinements distinct from headline model releases — the kind of infrastructure work that determines whether large customers can actually deploy at scale rather than just experiment.
Why it matters
Regional processing selection is a small feature on its face, but it addresses a real deployment blocker: enterprises with data-sovereignty obligations often can't consolidate workloads onto a single API account if that account is bound to one region. Letting a single Global-geography project route individual requests to different regions means fewer parallel integrations, simpler key management, and less duplicated infrastructure for customers operating across borders.
It's also a competitive-positioning move. AWS, Google Cloud, and Microsoft Azure have long offered region-pinning as a baseline enterprise capability; OpenAI matching that at the request level — rather than the account level — narrows a gap that has pushed some regulated customers toward Azure OpenAI Service instead of OpenAI's own API. Combined with the existing data-retention and eligibility controls staying in force, OpenAI is signaling this is additive to its compliance posture rather than a loosening of it.
Corroborating sources
- Developers.openai
https://developers.openai.com/api/docs/changelog
“API customers can now select regional processing for an individual request by using a prefixed domain with an API key from a project having Global geography.”