Docs
Regional routing & residency
Every model in the Anoman catalog declares the region where its requests are processed. You can route by residency, audit which region served any past request, and opt in (or out) of cross-border processing per request.
What “data processing region” means
When you call /v1/chat/completions, Anoman forwards the prompt to the upstream service that runs the model you chose. The data processing region is where that forwarding terminates — the country whose laws govern the prompt while it’s being processed.
The region is declared in two places: on the model detail page (the residency badge in the hero) and on every /public/v1/pricing row as dataProcessingRegions: string[]. Multiple regions = multi-region routing within that model’s infrastructure.
Supported regions
| Region | Code | Framework | Description |
|---|---|---|---|
| Indonesia | id | UU PDP | Indonesia data center (Jakarta). All Indonesian customer data is processed and stored here. |
| Singapore | sg | PDPA | Singapore region launches Q3 2026. Reserved for PDPA workloads. |
| China | cn | PIPL | Routing through Chinese infrastructure. Used by our cost-optimized open-source model catalog. |
| United States | us | — | Default routing region for most frontier flagship models. |
| Europe | eu | GDPR | EU-resident frontier models. |
| Japan | jp | APPI | Reserved for future Japan-resident routing. |
| Global | global | Multi-region | Multi-region routing — picks the fastest available region. No residency guarantee. |
How to route by region
There are three ways to align your model choice with residency policy:
1. Browse the catalog
Open /models and use the Region filter row at the top. Cards show a flag badge so residency is visible at a glance.
2. Query the public pricing endpoint
# Curl example — get all models that process in Indonesia only
curl -s https://api.anoman.io/public/v1/pricing \
| jq '[.[] | select(.dataProcessingRegions | index("id"))]'3. Audit per-request region from traces
Open the Traces page in the dashboard and filter by Region. Every trace row carries the region tag that served the request, so historical audits answer “where did this prompt actually go” deterministically.
Cross-border processing is opt-in
Customer accounts are pinned to a single region (customer_region on the API key). Account-internal data — keys, policies, billing, traces — never leaves that region’s database.
But the model you pick may process the request body (prompts + completions) in a different region. We make this visible:
- Each model card declares its data processing region.
- The model detail page renders a residency badge chain in the hero.
- The dashboard playground picker shows the residency badge before you select a model.
If your compliance posture requires staying within Indonesia, stick to models whose dataProcessingRegions includes"id". The same applies to PDPA / GDPR / PIPL / APPI workloads.
Failover and region
When the primary route for a model is unhealthy, Anoman may auto-failover to a backup route. Failover never crosses region boundaries silently — the backup route’s region is listed in dataProcessingRegions if it differs from the primary, so the catalog still reflects every possible processing location for the request.
For broader compliance documentation see UU PDP, PDPA, Privacy Policy, and Security.