OpenAI added per-request regional processing on August 21, 2026, allowing eligible projects with Global geography to select a processing region through a prefixed domain. The change offers routing flexibility. It does not mean every model, tool, or category of data automatically falls within the same regional guarantee.
What the routing option changes
The dated release record introduces the feature. The data-controls guide documents it as an alternative to region-specific projects and says existing eligibility and retention-control requirements still apply.
For an application serving multiple organizational requirements, per-request selection can be a useful configuration boundary. Define that selection from trusted application policy rather than from arbitrary user text. The service call should make its intended region explicit and expose a failure when the supported route cannot be used.
Processing and storage are different promises
The guide distinguishes regional storage from regional inference and identifies exclusions, including system data and third-party services. Support for one regional capability does not imply support for the other. A selected domain also does not relocate the customer's own infrastructure.
Map the full request path: user device, application server, model endpoint, tools, logs, and persisted artifacts. Then check each part against the organization's actual requirement. This avoids a common mistake in procurement, where a single provider option is described as though it controls the complete system.
Model and tool choices remain constrained
Consult the current support matrix for the exact endpoint, model, snapshot, and processing tier. A feature supported globally can have different regional conditions. Treat a model upgrade as a potential routing-contract change and review it before rollout.
Do not silently send a failed regional request to a global service just to keep the application responding. If the region is a requirement, that behavior changes the requirement at the point of failure. Prefer a visible, actionable error and an authorized recovery path that the operator understands.
Verify routing without retaining private content
Record the application policy, selected endpoint, model identifier, and relevant request outcome. Avoid storing full prompts solely to prove that routing happened. A focused integration check can confirm that the intended configuration is used and that unsupported combinations fail visibly.
Per-request processing is useful when it fits a documented deployment policy and a supported service combination. It should be described as one available control, with its actual limits, rather than a stand-alone compliance determination. Buyers still need the contractual and technical evidence for their complete workflow.