Regional Execution

Models run where the data lives. By default, each request routes to the closest available region. Two HTTP headers override that: X-Region-Override pins a specific region, and X-World-Part-Override keeps traffic within a broader geographic zone.

	`X-Region-Override`	`X-World-Part-Override`
Scope	Exact region	Geographic zone
Example value	`eu-north-1`	`eu`
Use when	You need a specific data center	You want to stay in a geography without picking an exact region
If both are set	Wins	Ignored

Default behavior

When you make a request without any region headers, it routes to the closest available region. No configuration needed.

Region pinning

Pin to a specific data center with X-Region-Override. Use this when you have data-residency or compliance requirements that depend on a specific location.

curl https://api.slng.ai/v1/tts/slng/deepgram/aura:2-en \
  -H "Authorization: Bearer SLNG_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Region-Override: eu-north-1" \
  -d '{ "voice": "aura-2-thalia-en", "text": "Hello from Europe!" }' \
  --output hello.wav

World-part constraints

Keep traffic within a geographic zone with X-World-Part-Override. The best available region within that zone is selected. Use this when you need to stay within a geography but do not need a specific data center.

curl https://api.slng.ai/v1/tts/slng/deepgram/aura:2-en \
  -H "Authorization: Bearer SLNG_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-World-Part-Override: eu" \
  -d '{ "voice": "aura-2-thalia-en", "text": "Hello from somewhere in Europe!" }' \
  --output hello.wav

If both headers are present, X-Region-Override wins.

Available regions

Not every model is deployed in every region. Check Models by Region to see what is available where.

World part	Region ID	Location
`na`	`us-east-1`	US East
`eu`	`eu-north-1`	EU North
`ap`	`ap-south-1`	AP South
`ap`	`ap-southeast-2`	AP Southeast
`ap`	`asia-south1`	AP South
`ap`	`asia-southeast2`	Jakarta
`ap`	`australia-southeast1`	Sydney

World parts

A world part groups several regions under one value. Requests route to the best available region within that zone, which does not guarantee a specific country.

Value	Zone
`na`	North America
`eu`	Europe
`eu-non-eu`	Europe, non-EU
`ap`	Asia-Pacific
`me`	Middle East

If your compliance requirement depends on a specific country, use X-Region-Override with the exact region. A world part routes to the best region within a zone and does not guarantee a specific country.

Voice agent region config

Voice agents use a separate region field (us-east, eu-central, ap-south) that determines where the agent runs. It is not interchangeable with the platform headers above: the agent region ap-south, for example, routes to the platform region ap-south-1, but you set it through a different field. See the Voice Agents region table for the full mapping and the telephony country pinning each region applies.

Compliance

Regional execution is not just about latency. In regulated industries it determines where data can exist and which models can process it. These constraints are respected per request. If you need a particular model hosted in a region where it is not currently available, contact us.

Overview

Pipeline

Configuration

Unified API

Default behavior

Region pinning

World-part constraints

Available regions

World parts

Voice agent region config

Compliance

Next steps

Models by region

Adaptive Execution

​Default behavior

​Region pinning

​World-part constraints

​Available regions

​World parts

​Voice agent region config

​Compliance

​Next steps

Models by region

Adaptive Execution

Default behavior

Region pinning

World-part constraints

Available regions

World parts

Voice agent region config

Compliance

Next steps