Data residency

Keeping your inputs, prompts and results inside the EEA.

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's custom_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.