Data residency per request

An organization sets a default processing region in its residency settings. A request can also name a region itself with the region field, for example to keep an EU customer’s request in the EU while the rest of your traffic uses the default.

Request

{
  "model": "Amara S1.2",
  "region": "eu",
  "messages": [{ "role": "user", "content": "Fasse diese Beschwerde zusammen: …" }]
}

Without region, the workspace’s region applies, then the organization default.

Rules

1. The region must be in the organization’s allowed_regions. Otherwise: 403 region_mismatch.
2. A workspace whose region is locked refuses any other value with 403 region_mismatch.
3. Files, batches, memory stores and agent sessions are stored in the region they were created in. A request in eu that references a file stored in us is refused with 400 cross_region_resource, so data is never moved between regions silently.
4. Not every model is offered in every region. GET /v1/models?region=eu lists the models available there.

Response

The response header syntic-region names the region that processed the request. Log it if you must prove residency to customers or auditors.

Price

Proposed — not offered. Whether pinning us or eu costs more than global is an owner-level commercial decision that has not been made; no surcharge is offered or set. The cost report design includes region as a grouping so any difference would be visible.

Related

• Data residency settings
• Admin: residency settings
• Data retention