Skip to main content
GPU infrastructure across five regions on four continents. Telnyx will endeavor to process requests in the region nearest the ingress domain you call, but this is not guaranteed.

​
Routing

Inference processing is latency-based, influenced by the ingress domain you call, not by your account’s data locality setting. Telnyx will endeavor to process in the preferred region, but does not guarantee it: Calling a regional ingress domain (for example, api.telnyx.eu) directs requests to the nearest GPU region for that domain under normal conditions. Telnyx does not guarantee processing location: during failover or capacity events, requests are processed at the next-lowest-latency region rather than failing.

​
Selecting a region per request

Default routing is latency-based, as above. To ask for a specific region instead, send a region on the request, using the same vocabulary as your account’s Data Locality setting: mode controls how strictly it is applied:
  • preferred — the default when region is set. Telnyx tries that region first and falls back to another when the model cannot be served there, so a request that would otherwise have succeeded still succeeds.
  • strict — the request is served from that region or it fails. It is never redirected to another region.
A strict request that cannot be served in the region returns 422, distinguishing the reasons:
A strict request sent to the wrong region’s domain also returns 422 — see strict requires the matching domain below. Other rules:
  • mode without region is a 400, as are unknown values for either.
  • Supported for Telnyx-hosted models only. A request routed to an external provider (for example openai/* or anthropic/*) never passes through Telnyx model routing, so region cannot be enforced for it: strict returns a 400 rather than silently serving it from elsewhere, and preferred is ignored.
  • Not every model is deployed in every region. Availability changes as capacity moves; a strict request is the way to find out definitively, and preferred is the safe default when you want proximity without risking a failure.
Both parameters are accepted on the Chat Completions, Responses and Anthropic Messages endpoints.

​
strict requires the matching domain

region controls where inference runs. The ingress domain you call is a separate hop — it is where the request is received and authenticated before it reaches a model. A strict pin must be received in the region it names, not merely served there. Send one to another region’s domain and it returns a 422:
It is refused rather than forwarded because a request that could be forwarded has already entered the platform outside the region, so forwarding it would not keep the promise the pin makes. Call the domain for the same region from the table above:
Matching them also avoids a needless cross-region hop, so it is the lower-latency choice as well. mode: "preferred" and requests without a region are unaffected by which domain receives them.

​
Data Residency

Processing location and storage location are controlled separately:
  • Processing in transit is latency-based by default, influenced by the ingress domain you call (see Routing above); Telnyx will endeavor to process in the preferred region, but that alone is not a guaranteed processing location. For a request that must not leave a region, send region with mode: "strict" (see Selecting a region per request), which fails the request rather than serving it elsewhere.
  • Storage at rest depends on the endpoint. The chat completions endpoint does not store request or response data. The responses endpoint stores conversations, and that storage is governed by your Data Locality setting (US, EU, APAC, or Middle East).
For a full cross-product breakdown (including Voice AI Assistants), see the Data Residency & Compliance FAQ.

​
Roadmap

  • Region selection API parameter
  • Per-region model status and latency metrics
  • Edge inference for sub-50ms response times