Data residency

Data residency lets you choose the geographic region where a workspace’s requests are processed and its stored content is kept. Customers in the EU and in regulated industries often need to show that personal data stays inside one jurisdiction; a region setting makes that a property of the workspace rather than a promise in a contract.

Regions

Each region is a full copy of the API: models, files, batches, sessions and every other feature run inside it. A model is offered in a region only when it can be served there; GET /v1/models lists the regions per model.

How it works

• Region is a workspace setting. Each workspace has a data_region. Every key in the workspace inherits it. Different workspaces in one organization can use different regions.
• Set at creation, changed rarely. You choose the region when creating a workspace. Changing it later is possible only while the workspace holds no stored content (files, sessions, memory, vaults); otherwise set up a fresh workspace in the new region.
• Hosts. Requests can be sent to https://app.syntic.ai/v1 from anywhere: they are routed to the workspace’s region before any content is processed. For strict network control you can also use the regional host, for example https://eu.app.syntic.ai/v1, which refuses keys from workspaces in other regions.
• What stays in region: prompts, outputs, files, batch inputs and results, session events, execution traces, memories, vault secrets and caches.
• What is global: account and organization records, billing, usage records (token counts, costs, no content) and audit events. These hold no prompt or output content.

Per-request override

A later phase adds a syntic-region request header that may narrow (never widen) processing to a region the workspace allows, for organizations that run one workspace across several regions.

Set a workspace’s region

In the Console: Settings → Workspaces → New workspace → Data region. With the Admin API:

curl -sS https://app.syntic.ai/v1/organizations/workspaces \
  -H "Authorization: Bearer $SYNTIC_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -H "syntic-beta: admin-2026-11-01" \
  -d '{"name": "eu-production", "data_region": "eu"}'

const res = await fetch('https://app.syntic.ai/v1/organizations/workspaces', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.SYNTIC_ADMIN_KEY}`,
    'Content-Type': 'application/json',
    'syntic-beta': 'admin-2026-11-01',
  },
  body: JSON.stringify({ name: 'eu-production', data_region: 'eu' }),
})
console.log(await res.json())

import os, requests
 
ws = requests.post(
    "https://app.syntic.ai/v1/organizations/workspaces",
    headers={"Authorization": f"Bearer {os.environ['SYNTIC_ADMIN_KEY']}", "syntic-beta": "admin-2026-11-01"},
    json={"name": "eu-production", "data_region": "eu"},
).json()
print(ws["id"], ws["data_region"])

Responses from a workspace in a non-default region carry the header syntic-region: eu so you can verify routing in your logs.

Pricing and limits

• Regional processing may carry a surcharge on token prices, shown per model on Pricing when the region launches.
• Rate limits are counted per region.
• Some preview features may launch in us first; their pages say so.

Errors

Build notes for the platform team

• Design the workspace table with data_region from the start, even while only us exists, to avoid a migration later.
• Global routing must resolve the key’s workspace region before reading the body; only the auth header is inspected at the edge.
• Each region needs its own storage buckets, database for content tables, cache and model capacity. Usage records are replicated to the global billing store without content.

Related

• Data retention
• Workspaces
• Customer-managed keys