What it does
Data residency keeps your organization's data inside the EEA (European Economic Area: the 27 EU countries plus Iceland, Liechtenstein and Norway). The files you send us, the prompts in them and the answers we return are stored in Frankfurt, and processed on servers and GPU (graphics processing unit) machines in EEA countries.
It covers batch data: your uploads, your jobs and their results. It costs the same as running without it.
With EU data routing on, realtime requests stay in the EEA too when you send them to the EU realtime address, described under API addresses.
What stays in the EEA
The content of your uploads and jobs:
- input files, whether you upload them or we copy them from a URL
- the prompts in them, with any images, audio and video
- results: every job's result file
- embedding inputs, and the vectors we return for them
These are stored in our EU storage bucket in Frankfurt (Amazon Web
Services region eu-central-1) and processed on servers
and GPU machines in EEA countries.
What stays in the US
The records we need to run the service and bill for it stay in our US
region (Amazon Web Services us-east-1):
- job metadata: ids, status, timestamps, row counts, the model name,
the settings a job is submitted with (such as its
response_format), and error messages, which can quote a row'scustom_id - usage records: how many tokens each job and request used
- billing: credits, payments and invoices
- your organization and account: members, API keys and settings
Turning it on
We turn EU data routing on for an organization on request. Write to support@anex.sh and tell us which organization it is for. The console's organization settings show whether it is on, and the EU API addresses once it is.
Once it is on, every new upload and job keeps its data in the EEA.
To keep a single upload or job in the world region, send
"data_residency": "world" on POST /inputs
(a direct upload or a copy from a source_url) or on
POST /jobs. World data is stored in the US and runs
wherever GPU capacity is cheapest. Inputs and jobs keep the region
they were created in, even if EU data routing is later turned off.
An organization without EU data routing that sends
"data_residency": "eu" gets 403:
"EU data routing is not enabled for this organization. Contact us to
enable it."
A job has to use an input stored in the same region, or the submit is
refused with 422. GET /jobs/{id} returns
data_residency, so you can check where every job ran. The
API reference has the full request shapes.
API addresses
The batch API has the same endpoints, and takes the same API keys, at two addresses:
- Main
https://api.anex.sh/batch/v1- EU
https://api-eu.anex.sh/batch/v1
Data kept in the EEA is stored and read by the EU API. Your existing
code can keep the main address and handle one response: a request that
needs such data (creating or polling an EU input, submitting an EU job,
downloading an EU job's result) answers 421 with a body
naming the API to use:
HTTP/1.1 421 Misdirected Request
{"detail":"this job is stored in the EU region; use https://api-eu.anex.sh",
"residency":"eu","api":"https://api-eu.anex.sh"}
Send the same request, with the same path, to the origin in
api. If all of your organization's data is kept in the
EEA, use the EU address for everything: checking a job's status,
approving and cancelling answer at either address.
A direct upload goes from your machine straight to storage in the EEA, through the presigned target the EU API returns.
Realtime requests stay in the EEA when you send them to
https://api-eu.anex.sh/realtime/v1, which has the same endpoints
and takes the same keys as the main realtime API. It answers organizations
with EU data routing on, and it serves these models: qwen3-vl-embedding-8b.
Any other organization gets 403. If we cannot confirm
your organization's access at that moment, it answers 503
with a Retry-After header: retry after that many seconds.
GET /models at the EU address lists them too. A model it
does not serve answers 404 with
"<model> is not available in this region". The main
realtime address has no 421: it serves the request in
the US region.
GPU machines
The GPU machines that process data kept in the EEA are rented only in EEA countries.
Output length
When a job leaves out max_output_tokens, we estimate how
long its answers will be from a sample of its rows. For data kept in
the EEA the estimate can take longer: up to about an hour when no
machine is ready to run the model. A job can be cancelled while it
waits for its estimate.
Prices
Keeping data in the EEA costs the same as running anywhere. The prices are on pricing details.