Skip to main content
Telnyx operates API endpoints in multiple regions. Sending requests to a regional endpoint such as api.telnyx.eu routes request processing through that region’s infrastructure under normal conditions — reducing latency for applications operating in or serving that region, and directing request handling to the region for applications with data residency requirements. Processing location is not contractually guaranteed (see Processing vs. storage). Regional endpoints work with the same API keys, the same request and response shapes, and the same webhook payloads as api.telnyx.com. To change regions, change the base URL — no other integration changes are required.
Processing location depends on the endpoint you call and is subject to failover. Storage location is governed by your Data Locality setting and is not affected by the endpoint you call. See Processing vs. storage below.

Regional API endpoints

A regional endpoint is the domain you send REST requests to (api.telnyx.com, api.telnyx.eu, and so on). A point of presence (PoP) is the physical infrastructure site that serves a region — the EU PoP runs in Frankfurt, Germany. “Region” is the vocabulary shared with your Data Locality setting and, for AI products, the region request parameter. All endpoints serve the same REST API surface under /v2. Product availability varies by region — see Product availability.

Processing vs. storage

Telnyx distinguishes between where a request is processed and where data is stored at rest. The two are controlled independently: Sending to api.telnyx.eu alone does not change where data is stored at rest, and setting Data Locality to EU alone does not route request processing through the EU. Applications that need both processing and storage in the EU combine both controls:
  1. Send API requests to api.telnyx.eu.
  2. Set Data Storage Location to Germany under Account settings → Profile in the Mission Control Portal.
With both set, requests are processed in the EU under normal conditions and covered data types (CDRs, MDRs, recordings, and other Data Locality–governed data) are stored in the EU. The storage guarantee is contractual; the processing routing is subject to failover.
The regional endpoint directs requests to the region’s infrastructure but is subject to failover: if the primary regional site is unavailable, requests may be processed at another site rather than failing. Data Locality, by contrast, is a hard control over storage location. For AI products, stricter per-request region pinning is available — see Inference: Data Residency.

Getting started with api.telnyx.eu

Use the endpoint in place of api.telnyx.com with the same API key and request bodies. API keys work across all regional endpoints, and webhook configuration is unchanged — deliveries originate from the same webhook infrastructure regardless of the endpoint used to submit the request. Send an SMS through the EU endpoint:
SDKs default to https://api.telnyx.com/v2. Override the base URL with the base_url / baseURL client option (Python, Node, Ruby, Go, Java) or the configuration setters shown (.NET, PHP).
Voice calls and SIP trunking route through the region by setting the application’s AnchorSite® to an EU site (Frankfurt, Amsterdam, or London) and using the regional SIP endpoint — see Voice API Services in Europe and AnchorSite Configuration.

Message flow through the EU PoP

An outbound SMS sent to api.telnyx.eu takes this path:
  • Under normal conditions, requests hitting api.telnyx.eu are received by the EU API gateway and processed by messaging services in the Frankfurt region rather than being routed to US or other regions’ messaging services. During failover, processing may shift to another region — see Processing vs. storage.
  • The Message Detail Record (MDR) is written to the storage region governed by the account’s Data Locality setting.
  • Webhook deliveries (message status updates, inbound messages) are sent from the messaging platform’s webhook infrastructure to the URLs configured on your messaging profile, independent of the endpoint used to submit the original request.

Product availability

Not every product processes in every region. Confirm behavior for your use case before making residency commitments to your own customers.
WhatsApp traffic sent to api.telnyx.eu is processed by the US WhatsApp service. Applications with EU WhatsApp traffic and strict residency requirements should contact the Telnyx account team to confirm current options.

Rate limits

API rate limits are counted per region. A request limit reached on api.telnyx.com does not carry over to api.telnyx.eu — each regional endpoint enforces its limits independently. When integrating failover across regions, note that a 429 Too Many Requests on one region’s endpoint does not indicate the state of another region’s limits. See API rate limiting for general rate-limit behavior and headers.

GDPR and EU data residency

The EU PoP exists for applications subject to GDPR and similar EU data-protection requirements. The practical controls and their scope:
  • Processing in the EU: requests sent to api.telnyx.eu are received and processed by infrastructure in the Frankfurt region. Processing location is not contractually guaranteed under all conditions (see failover).
  • Storage in the EU: setting Data Locality to Germany stores covered data types (MDRs, CDRs, recordings, transcripts, and more) in the EU. This is an account-level, one-time setting. The covered-data-types list is not exhaustive — see Data Locality for the authoritative list.
  • Combining both pairs EU-oriented request processing with EU storage at rest for Data Locality–covered data types. The storage leg is a hard control; the processing leg is not (see the warning above).
Telnyx does not contractually guarantee blanket “EU-only processing” for all products. Some components — for example, third-party service providers, or operational and security handling — may involve activity outside a single region. Review the product-specific sections above and confirm written data commitments with your account team and DPA before making representations to your own customers or auditors.