OpenAI data residency in India and the UAE: what stays local
OpenAI data residency in India stores data locally but processes it elsewhere. The UAE does both, for five models. What each option guarantees and costs.
OpenAI data residency in India gives you regional storage, not regional processing. OpenAI's data controls guide lists in.api.openai.com with regional storage but no regional processing, so your stored content stays in India while inference can still run elsewhere. The UAE endpoint, ae.api.openai.com, does both, for a short list of models and only after extra approval. This post maps what each option actually guarantees, what it costs, and how to design around the gaps.
If a compliance team in Mumbai or Dubai has asked you "where does our data go when it hits the model?", the honest answer depends on three things: the region, the endpoint and the exact model snapshot. Get any one of them wrong and a project configured for residency can still send customer content out of the region to be processed.
OpenAI data residency: the two words that mean different things
OpenAI splits residency into two separate promises. Regional storage means your customer content is stored at rest in the selected region, but only "to the extent the endpoint requires data persistence to function", with batches given as the example. Regional processing is a second, narrower promise: if the region supports it, OpenAI also performs inference in that region.
The guide is blunt about what happens when a region offers only the first. If your selected region does not support regional processing, OpenAI may also process and temporarily store customer content outside the region to deliver the services. It also states, in so many words, that support for regional storage does not imply support for regional processing.
That sentence is the whole post in miniature. A project pinned to India keeps its files, vector stores and batch inputs in India. The prompt that goes to the model, and the completion that comes back, can be handled somewhere else.
What each region promises, as of September 2026
Here is the relevant part of OpenAI's support-by-region table, trimmed to the regions our clients most often ask about. "MAM or ZDR required" means the project must be approved for Modified Abuse Monitoring or Zero Data Retention before it can use the region.
| Region | Domain prefix | Regional storage | Regional processing | MAM or ZDR required |
|---|---|---|---|---|
| India | in.api.openai.com | Yes | No | Yes |
| United Arab Emirates | ae.api.openai.com | Yes | Yes (listed models only) | Yes, plus additional approval |
| Europe (EEA + Switzerland) | eu.api.openai.com | Yes | Yes | Yes |
| United States | us.api.openai.com | Yes | Yes | No |
| Australia | au.api.openai.com | Yes | No | Yes |
Canada, Japan, Singapore, South Korea and the United Kingdom sit in the same row shape as India: storage yes, processing no. So India is not being singled out. Regional processing outside the US and Europe exists in exactly one place today, and that is the UAE.
Does OpenAI store data in India?
Yes, for supported endpoints in a project configured for the India region. The India storage services list covers audio transcription, translation and speech, batches, Chat Completions, embeddings, files, fine-tuning jobs, image generation and edits, moderations, the Responses API with file search and web search, vector stores, Code Interpreter and file uploads. Image support in India, like in the other asterisked regions, requires approval for enhanced Zero Data Retention or enhanced Modified Abuse Monitoring.
Can OpenAI process data in India?
Not as of September 2026. The India row lists processing services as "None". That is not a gap in one endpoint; no service is processed in-region for India today. If your requirement is that inference itself happens on Indian soil, the OpenAI API's regional endpoints do not meet it yet, and you should hear that from your engineering partner before a contract is signed rather than after.
The UAE processes in-region, for five models
The UAE is the more interesting case, and the one most summaries get slightly wrong. The region does support regional processing, but the processing services cell for the UAE is short:
- Chat Completions:
gpt-5.6-luna,gpt-5.5-2026-04-23,gpt-5.2-2025-12-11 - Responses:
gpt-5.5-pro-2026-04-23,gpt-5.6-luna,gpt-5.5-2026-04-23,gpt-5.2-2025-12-11 - Embeddings:
text-embedding-3-large
Notice what is missing. GPT-6 Astra, GPT-5.6 Sol and GPT-5.6 Terra all appear in the UAE storage list for the Responses API, but not in the processing list. A Dubai project that runs Astra keeps its stored state in the UAE but gets no regional processing guarantee for inference. If you are weighing those models, our comparison of GPT-6 Astra vs GPT-5.6 is worth reading with this table open next to it.
Audio, image generation, moderation, file search, web search, Code Interpreter and the remote MCP server tool are processed only in the US and Europe. In the UAE they can store data but not process it.
OpenAI API data residency UAE approval
Two gates apply. Any region other than the United States requires approval for abuse monitoring controls and a signed Modified Retention amendment. On top of that, selecting the UAE region requires additional approval through OpenAI's sales team. Budget calendar time for both before a UAE launch date goes into a plan.
How do I enable OpenAI data residency?
Residency is configured per project inside your API organisation. The sequence, from the data controls guide:
- Ask OpenAI's sales team whether your organisation is eligible for data residency controls.
- For any non-US region, get approved for Modified Abuse Monitoring or Zero Data Retention and execute the Modified Retention amendment. For the UAE, get the additional approval.
- Create a new project and pick the region from the dropdown. The guide describes setting a region "for new projects you create"; it does not describe moving an existing project.
- Send every request for that project to the region's prefixed domain, for example
https://in.api.openai.com/v1. - Check each endpoint, tool and model snapshot you call against the support table. Anything outside it is outside the guarantee.
Step three catches teams out. If your production traffic lives in a project created before residency was approved, you are creating a new project, issuing new keys and cutting traffic over. That is a migration, with the usual key rotation work described in our post on OpenAI API key security.
OpenAI per request regional processing, since 21 August
On 21 August 2026 OpenAI added per-request regional processing: you can send an individual request to a prefixed domain using an API key from a project with Global geography, instead of creating a region-specific project. The guide's example reuses one client and one Global key, and switches the base URL to us.api.openai.com or eu.api.openai.com per call.
The limits come in the next sentence. Existing eligibility and data retention control requirements still apply, and the endpoint and model must support regional processing. For India that makes per-request routing moot, because there is no regional processing to select. For the UAE it can work, but only for the five models above, and only once the approvals are in place.
Where this helps is a mixed workload. A single application can keep general traffic on the Global project and route the regulated slice, say an Emirati customer's case notes, to ae.api.openai.com with a model that the UAE actually processes.
OpenAI regional endpoint pricing: the 10% uplift
Regional processing (data residency) endpoints are charged a 10% uplift for models released on or after 5 March 2026 that are eligible for data residency. Older snapshots such as gpt-5.2-2025-12-11 predate that cut-off; newer ones such as the GPT-5.6 family do not.
A worked example, using published standard prices and stated assumptions. GPT-5.6 Luna lists at $0.20 per million input tokens and $1.20 per million output tokens. Assume 10,000 requests a day at 2,000 input and 500 output tokens each:
| Line | Calculation | Per day |
|---|---|---|
| Input | 20M tokens × $0.20 per 1M | $4.00 |
| Output | 5M tokens × $1.20 per 1M | $6.00 |
| Global endpoint total | $4.00 + $6.00 | $10.00 |
| Regional endpoint (+10%) | $10.00 × 1.10 | $11.00 |
The uplift is rarely what kills a business case. The approval timeline and the model restrictions usually matter more.
One wording difference is worth raising with OpenAI before you budget. The pricing page says "regional processing (data residency) endpoints", while the data controls guide says data residency endpoints are charged the uplift, without the word processing. Whether a storage-only India project pays the 10% is something to confirm in writing, not assume either way.
Is the OpenAI API compliant with data localisation?
That depends on what your localisation obligation actually requires, and we are not your lawyers. What we can say is what the documentation does and does not cover, so the question you put to counsel is precise. Whatever your reading of India's Digital Personal Data Protection Act or a sector regulator's rules, the useful question is rarely "is the data stored locally?" It is "where is it processed, and what leaves?"
Data residency does not apply to system data: account data, metadata, usage data, analytics, billing information, support requests and, notably, structured output schemas. It also does not cover transmission caused by where your end users or your own infrastructure sit, or products offered by third parties through the services. That last point matters for tool use: data you send to a remote MCP server is subject to that server's retention policy, not OpenAI's.
Several endpoint-level details also move data. In regions without regional processing, extended prompt caching may require OpenAI to process and temporarily store customer content outside the region. In non-US regions you cannot set store=true on Chat Completions. Realtime and GPT-Live have residency support only in the US and Europe, and files and vector stores have regional storage but no regional processing anywhere. If your cost plan leans on caching, read our note on prompt caching alongside this caveat.
There is also a transport detail the guide states only for two regions. For requests 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. The guide does not make the same statement for India or the UAE. If your auditor asks where TLS terminates for ae.api.openai.com, that is a question for OpenAI, not something to infer.
Designing around the gaps
The strongest counter-argument to all this caution is that storage is what most regulators actually ask about, and a storage-only region satisfies plenty of real policies. That is often true. Batch inputs, uploaded documents, vector stores and fine-tuning data are the long-lived copies, and India keeps those local. If your policy is about data at rest, India residency may be all you need.
It is the wrong choice if the policy says processing, or if a customer contract promises that personal data "never leaves the country". For those, the patterns we use in the builds we run look like this:
- Minimise before you send. Strip or tokenise identifiers in your own in-country service, send the model only what the task needs, and re-attach identity on the way back.
- Split by sensitivity. Route regulated records through a region and model that the table says are processed locally, and keep general traffic on Global. Per-request routing makes this a base-URL decision, not a second codebase.
- Pin snapshots, not aliases. The UAE processing list names dated snapshots. An alias that silently moves to a newer model can move you outside the processing guarantee.
- Keep state you control. Server-side conversation and response storage follow each endpoint's retention rules. Keeping history in your own database, in your own region, keeps the decision with you.
None of this is exotic. It is the same data-flow mapping any regulated integration needs, applied to an API whose guarantees differ by region, endpoint and snapshot. As an OpenAI Select Partner, we do this mapping as part of our AI engineering services, and our software development practice in Dubai gets the UAE version of this question more than any other.
The next decision is concrete. Before you request residency, write down which of your calls touch regulated data, which endpoint and snapshot each one uses, and whether your obligation is storage or processing. Then hold that list against OpenAI's table. If every row passes, apply. If one does not, you have found your design problem early, and cheaply.
Frequently asked questions
No. OpenAI data residency in India, via in.api.openai.com, offers regional storage but not regional processing as of September 2026. Customer content that an endpoint needs to persist is stored at rest in India, but OpenAI may process and temporarily store customer content outside the region to deliver the service.
OpenAI's UAE region processes gpt-5.6-luna, gpt-5.5-2026-04-23 and gpt-5.2-2025-12-11 on Chat Completions and Responses, gpt-5.5-pro-2026-04-23 on Responses, and text-embedding-3-large on embeddings. Other models, including GPT-6 Astra, can store data in the UAE region without a regional processing guarantee, so check the exact snapshot before promising a client in-country inference.
OpenAI charges a 10% uplift on data residency endpoints for eligible models released on or after 5 March 2026, according to its pricing page and data controls guide. Older snapshots released before that date do not carry the uplift. Confirm with OpenAI whether a storage-only region such as India is billed the uplift.
OpenAI's data controls guide describes selecting a region when you create a new project, not changing the region of an existing one. In practice, plan to create a new region-configured project, issue new API keys for it, and cut production traffic over, rather than expecting to change an existing project's region.
Using OpenAI data residency in any region other than the United States requires approval for abuse monitoring controls, meaning Modified Abuse Monitoring or Zero Data Retention, and a signed Modified Retention amendment. The UAE region needs additional approval through OpenAI's sales team, and eligibility for residency itself is confirmed by sales.
No. OpenAI data residency covers customer content only. System data such as account details, metadata, usage statistics, billing information, support requests and structured output schemas may be processed and stored outside the selected region. Data sent to third-party services, such as a remote MCP server, follows that provider's own policies.
