On this page · 9 sections
Summary. On 21 August 2026 OpenAI's API changelog added the ability to "select regional processing for an individual request by using a prefixed domain with an API key from a project having Global geography." Before that, a region was a property of the project, so a team serving India and the EU needed 2 projects and 2 keys. The change is real and it removes a genuine operational tax. What the changelog does not say is that OpenAI's own support table lists 10 residency regions and marks only 3 of them, the United States, Europe and the United Arab Emirates, as supporting regional processing. The other 7, including India at in.api.openai.com, the United Kingdom, Japan, Canada, Australia, Singapore and South Korea, are marked Storage Yes, Processing No. Residency endpoints also carry a 10% uplift for models released on or after 5 March 2026. At the GPT-5.6 Sol price of $4 per million input and $20 per million output tokens, that is $4.40 and $22.
What actually changed
The changelog entry is dated 21 August 2026 and is one sentence long. It says existing "eligibility, data retention control, endpoint, and model support requirements continue to apply" (OpenAI API changelog).
The mechanics are in the data controls guide. Previously, data residency was configured per project: you picked a region from a dropdown when creating the project, and every request from that project's key went to the matching prefixed domain. Now a single key from a Global-geography project can hit any eligible prefixed domain by overriding the base URL. OpenAI's own example reuses one client for three destinations, the default endpoint, https://us.api.openai.com/v1 and https://eu.api.openai.com/v1, with gpt-5.6-terra in all three calls (data controls guide).
For a platform team, one key instead of three is the whole benefit. Key rotation, secret storage, budget alerts and rate-limit accounting all collapse back to one object.
The part the announcement leaves out
Storage residency and processing residency are separate columns in OpenAI's table, and the guide is explicit that "Support for regional storage does not imply support for regional processing."
| Region and prefixed domain | Storage in region | Inference in region |
|---|---|---|
United States, us.api.openai.com |
Yes | Yes |
Europe (EEA + Switzerland), eu.api.openai.com |
Yes | Yes, requires MAM or ZDR |
United Arab Emirates, ae.api.openai.com |
Yes | Yes, requires MAM or ZDR |
India, in.api.openai.com |
Yes | No |
United Kingdom, gb.api.openai.com |
Yes | No |
Japan, jp.api.openai.com |
Yes | No |
Canada, ca.api.openai.com |
Yes | No |
Australia, au.api.openai.com |
Yes | No |
Singapore, sg.api.openai.com |
Yes | No |
South Korea, kr.api.openai.com |
Yes | No |
Source: OpenAI data controls guide, retrieved 22 August 2026.
The consequence is written into the same page: "If your selected Region does not support regional processing, as identified below, OpenAI may also process and temporarily store Customer Content outside of the Region to deliver the services."
So an Indian bank pointing traffic at in.api.openai.com gets data at rest in India and inference somewhere else, with temporary storage outside India permitted while the request is served. If your compliance position rests on in-country inference rather than in-country storage, the prefixed domain does not give it to you. That distinction is what a legal review will find in month three, not week one.
There is a second, quieter signal. The guide names Cloudflare Regional Services as the mechanism that keeps TLS termination in region, and names it for exactly two hostnames: "For requests sent to us.api.openai.com or eu.api.openai.com, OpenAI uses Cloudflare Regional Services so that TLS termination and HTTPS decryption occur within the selected processing region." Cloudflare's own documentation describes the same behaviour, where an HTTPS request from the US destined for an EU-regionalised hostname "will be forwarded in encrypted form to an EU data center before being decrypted" (Cloudflare Regional Services). The other eight hostnames are not named in that sentence.
The eligibility gate nobody costs in
Per-request switching does not lower the entry price. Two conditions still apply before any non-US prefixed domain works.
First, approval. "To use data residency with any region other than the United States, you must be approved for abuse monitoring controls, and execute a Modified Retention amendment." The UAE region needs a further approval on top of that. Both routes run through OpenAI sales, not a console toggle.
Second, the amendment changes runtime behaviour. Zero Data Retention, one of the two qualifying controls, forces store to false on /v1/responses and /v1/chat/completions "even if the request attempts to set the value to true." Any code path relying on previous_response_id for server-side conversation state stops working the day the amendment takes effect. Teams that built stateful agents on the Responses API should treat that as a migration, not a config change. We covered the wider set of endpoint restrictions in OpenAI zero data retention limits.
Then there is the bill. The guide states that "Data residency endpoints are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." OpenAI's changelog of 20 August 2026 put GPT-5.6 Sol at $4 per million input tokens and $20 per million output tokens, describing it as promotional pricing available at least through 21 November 2026. Vercel's changelog on 21 August described the same numbers as "list pricing" (Vercel changelog). Those are different claims about the same figure, and only one of them carries an expiry date. Budget against the promotional reading.
| Cost line, GPT-5.6 Sol | Global endpoint | Residency endpoint |
|---|---|---|
| Input, per million tokens | $4.00 | $4.40 |
| Output, per million tokens | $20.00 | $22.00 |
| 100M input + 20M output per month | $800 | $880 |
| Annualised at that volume | $9,600 | $10,560 |
Prices as published 20 August 2026, uplift applied per the data controls guide. The uplift is a routing decision now, so a per-request switch is also a per-request price switch. If you mix global and regional calls behind one key, your unit economics stop being a single number.
India: the alternative that does infer locally
For in-country inference in India, the workable path in August 2026 runs through AWS rather than the OpenAI API directly. On 18 August 2026 AWS added GPT-5.6 Terra and Luna to Amazon Bedrock in India with India Geo cross-Region inference, using the profiles in.openai.gpt-5.6-terra and in.openai.gpt-5.6-luna, routing "only within the India geography, across AWS Regions such as Asia Pacific (Mumbai) and Asia Pacific (Hyderabad)" (AWS What's New, 18 August 2026).
The trade is cost and model coverage. AWS's 17 August 2026 announcement states that "Global inferencing is priced lower per token for OpenAI models than in-Region and Geo inferencing" (AWS What's New, 17 August 2026). India Geo also lists Terra and Luna only, while the Bedrock launch that added cross-Region inference covers Sol, Terra and Luna. If Sol is your production model, India Geo is not a like-for-like swap. The comparison against calling OpenAI directly is in Bedrock versus OpenAI direct cost math.
Azure draws the same storage-versus-processing line, and says so more plainly than OpenAI does. Microsoft's deployment-type documentation states that data at rest "remains in the designated Azure geography," while Global deployment types "may be processed in any Azure region" and Data Zone types process "only within the Microsoft-specified data" zone (Microsoft Foundry deployment types). Azure's GPT-5.6 series listing covers Sol, Terra and Luna (Foundry Models sold by Azure).
| Route for Indian workloads | Storage in India | Inference in India | GPT-5.6 models available |
|---|---|---|---|
OpenAI in.api.openai.com |
Yes | No | Per residency support table |
| Bedrock India Geo profiles | Yes, Mumbai and Hyderabad | Yes | Terra, Luna |
| Bedrock Global cross-Region | No | No | Sol, Terra, Luna, lowest per-token price |
| Azure Global deployment | Designated geography | Any Azure region | Sol, Terra, Luna |
| Azure Data Zone deployment | Designated geography | Within the data zone | Sol, Terra, Luna |
How to tell whether this affects you
Three checks, each of which takes under an hour.
Read your own commitment language first. If a customer contract, a DPDP-driven data-flow map or a regulator submission says processing happens in India, the UK, Japan, Canada, Australia, Singapore or South Korea, and you are relying on an OpenAI prefixed domain to deliver it, the support table contradicts you today. Our DPDP consent manager readiness note covers how those flow maps usually get written.
Second, check what residency never covered. The guide excludes system data, defined as "account data, metadata, and usage data that do not contain Customer Content," and names structured output schema among the examples. A JSON schema is a design artefact, and teams routinely encode business logic and field names into one. That leaves the region regardless of which hostname you call.
Third, check your model lifecycle exposure. OpenAI's deprecations page gives at least 6 months' notice for generally available models, at least 3 months for specialised variants such as Codex and deep research builds, and as little as 2 weeks for anything with preview in the name (OpenAI deprecations). Regional processing depends on a specific model and snapshot appearing in the support table. A 2-week preview retirement can take a regional route away faster than a procurement cycle can replace it.
What is still unknown
OpenAI has not published a date for regional processing in India, the UK, Japan, Canada, Australia, Singapore or South Korea, and the guide gives no roadmap language beyond expanding availability over time. The 10% uplift applies to models released on or after 5 March 2026 that are eligible for residency, but the guide does not state whether the uplift compounds with the promotional Sol pricing when that promotion ends on or after 21 November 2026. Nor does it say whether per-request switching will extend to storage-only regions in a way that changes their processing status. Until those are documented, treat the storage and processing columns as the binding statement and everything else as intent.
The wider point for anyone running EU obligations alongside Indian ones: the same split shows up at other vendors, and we tracked one version of it in Mistral EU residency and ZDR gaps. Read the table, not the headline.
FAQ
How eCorpIT can help
Regional routing decisions like this one sit at the join of architecture and legal drafting, which is where they usually go wrong. Our teams map the actual data flows, separate the storage claim from the processing claim, and rebuild the routing so the contract language and the runtime behaviour match, including the multi-provider fallback most Indian regulated workloads end up needing. That work is described on our data residency and DPDP cloud architecture page, and it starts from your existing flow map rather than a template. Talk to us at /contact-us/, or start with the broader DPDP engineering playbook.
References
- OpenAI API changelog — entries dated 21 and 20 August 2026, retrieved 22 August 2026.
- Data controls in the OpenAI platform — data residency controls, regional support table, uplift and limitations.
- Data controls in the OpenAI platform, platform mirror — same content served from the platform domain.
- OpenAI deprecations — model deprecation notice periods.
- Cloudflare Regional Services — in-region TLS termination behaviour, last updated 23 July 2026.
- Cloudflare Regional Hostnames — how a region is assigned to a proxied hostname.
- Amazon Bedrock now supports OpenAI models in India — AWS What's New, 18 August 2026.
- Amazon Bedrock expands API support and introduces Cross Region Inferencing for OpenAI models — AWS What's New, 17 August 2026.
- Deployment types for Microsoft Foundry Models — global, data zone and regional processing behaviour.
- Foundry Models sold by Azure — GPT-5.6 Sol, Terra and Luna availability.
- Vercel changelog — 21 August 2026 entry describing GPT-5.6 Sol pricing.
Last updated: 22 August 2026.