AuthPI stores identity data close to your users. Every issuer is provisioned with eight regional identity stores spread across the world. When a user signs up, AuthPI places their identity in the store nearest to where the request came from, and that is where their profile and credentials live from then on. Authentication for that user is served from the same region.

We call this the Global Identity Mesh. This page explains exactly how placement works, which guarantees are hard and which are best-effort, and what data is regional versus global. Identity infrastructure is a trust product, so this page errs on the side of precision.

Why placement matters

Most identity providers keep all user data in one region, usually the US or the EU. Every login crosses the world to reach it. And if your requirements say European users’ data should stay in Europe, you are typically looking at separate regional deployments, routing logic, and synchronization, or a “data residency” line item on an enterprise contract.

AuthPI distributes identity storage instead. Users are placed in a region automatically at signup, authentication happens near them, and signups from Europe land in stores with a platform-enforced EU jurisdiction guarantee. You deploy nothing extra to get this.

How placement works

Placement is automatic and happens once, at signup.

1. AuthPI reads the country of the signup request, as seen at the network edge.
2. The country maps to one of the eight store regions. A signup from Germany maps to Western Europe; a signup from Japan maps to Asia-Pacific.
3. The user’s identity is created in that region’s store. If the mapped region has no available store, placement falls back to the nearest region that does, defaulting to Western Europe.

The assignment is permanent. A user’s identity data stays in its store for the lifetime of the account. Nothing moves it between regions implicitly (see moving between regions).

The assignment is visible. The Core API’s list users response includes a region field for every user, derived from the store they were placed in. When someone asks where a specific user’s data lives, the answer is one API call.

There is no issuer-wide residency configuration to manage. No per-issuer region setting and no per-organization override. Placement follows the user’s signup location unless a Core API caller explicitly requires a supported region or the EU jurisdiction when creating the user.

For API-created users, stated plainly. Without an explicit placement requirement, users created directly through the Core API default to the API caller’s geography, which is usually the operator or migration host rather than the end user’s location. If you require residency at creation, specify a supported region or the EU jurisdiction; AuthPI rejects the request rather than placing the user elsewhere when that requirement cannot be satisfied.

The regions

These are the eight regions actually provisioned for every issuer, and the guarantee each one carries:

Region	Signups routed from	Placement guarantee
Western Europe	UK, France, Germany, Spain, Netherlands, …	Hard: EU jurisdiction, platform-enforced
Eastern Europe	Poland, Romania, Czechia, the Baltics, …	Hard: EU jurisdiction, platform-enforced
Western North America	Western US and Canada, Mexico	Best-effort placement
Eastern North America	Eastern US and Canada	Best-effort placement
South America	Brazil, Argentina, Chile, Colombia, …	Best-effort placement
Asia-Pacific	India, Japan, Singapore, South Korea, …	Best-effort placement
Oceania	Australia, New Zealand, …	Best-effort placement
Middle East	UAE, Saudi Arabia, Israel, Egypt, …	Best-effort placement

Two footnotes worth stating plainly:

• There is no dedicated African region today. Signups from Africa are routed to Western Europe, which carries the EU jurisdiction guarantee.
• There is no India-specific placement. Signups from India route to the Asia-Pacific region.

Hard guarantees and best-effort placement

The eight regions are not created equal, and the difference matters if you are making compliance claims.

The two European regions carry a hard guarantee. Their stores are created under Cloudflare’s EU jurisdiction restriction, which limits where the store may ever run and keep data at the platform level. This is enforced by the infrastructure, not by a policy we promise to follow. When we say identity data in the European regions stays under EU jurisdiction, that claim is architectural and auditable.

The other six regions are best-effort placement. Their stores are created with a location hint, which the platform honors in practice but treats as advice rather than a contract. A store hinted to Oceania runs in Oceania under normal conditions, but placement is not contractually pinned the way EU jurisdiction is. We say best-effort because that is what it is.

If you need the hard version of this guarantee, it exists today only for the two European regions.

What stays regional and what is global

The residency story applies to personal data, not to every byte in the system. Here is the actual split.

Regional, stored only in the user’s identity store: the user’s profile, sign-in credentials and verifiers (passwords, passkeys, one-time codes), trusted devices, consent grants, and account security state. This is the personal data placement is about, and it does not leave the assigned region.

Global, not pinned to a region:

• The routing index. A global index records which store and region holds each user, so a sign-in can be routed to the right store. It contains routing data, not profile data, and it does not store readable sign-in identifiers. For users who sign in through an external OAuth provider, the linked provider reference is indexed globally the same way; the email from the provider stays in the user’s regional store.
• Configuration objects. Accounts, issuers, clients, organizations, and agent definitions are configuration rather than user PII, and they follow the platform’s default placement.
• Events and audit data. Events emitted by regional stores are processed and stored centrally in our analytics infrastructure, currently in the EU. Audit history is not kept per region.
• Webhook delivery. Webhooks are configured by event type, not by region, and deliveries originate from shared infrastructure.

Sessions follow the store. Session state lives in dedicated session objects created by the user’s identity store, and they inherit the store’s placement: the same region, and for the two European regions the same EU jurisdiction restriction.

Routing a sign-in

Signup picks a region; sign-in has to find one. When an existing user signs in, AuthPI resolves which store holds them at the network edge, using routing data only: no profile data is read or moved to do it. Once the store is known, the rest of the authentication happens there, in the user’s region.

Moving between regions

Placement is permanent today. A user assigned to Asia-Pacific at signup stays in Asia-Pacific: there is no supported way to move a user’s identity data to another region, and nothing moves it behind your back. That is a deliberate default, since silent cross-region moves are exactly what residency requirements exist to prevent.

A supported migration process, for cases like a user relocating or a contract requiring a specific region, is on the roadmap. Until it ships, the honest answer to “can I move this user to Europe?” is no.

Compliance posture

AuthPI’s architecture is designed to help you meet data residency requirements. It does not make your application compliant on its own, and we will not pretend otherwise.

What you can claim, and demonstrate:

• User identity data is placed in a region at signup, and the assigned region is visible per user through the API.
• Identity data in the two European regions is kept under EU jurisdiction by a platform-level restriction, not by policy.
• Identity data does not move between regions.

What remains yours: your own application data, your lawful basis for processing, and the regulatory analysis for your specific situation. For contractual terms, see the Data Processing Agreement on our legal page.

Getting started

The mesh is not a feature you enable. When you create an issuer, its eight regional stores are provisioned with it, and every signup from then on is placed automatically.

1. Register for an account if you haven’t already
2. Follow the quickstart to create your first issuer
3. Sign in your first users, then check the region field in the users list to see placement in action

Next steps

• Learn about issuers and how to configure authentication
• Understand users and identity management
• Explore organizations for multi-tenant applications
• Review our OIDC compliance for standards details