> ## Documentation Index
> Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Regional Endpoints & the EU PoP

> Send requests to Telnyx regional API endpoints — api.telnyx.com, api.telnyx.eu, and more — to reduce latency and process requests in-region under normal conditions. Combine with Data Locality for EU data residency at rest.

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](#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.

<Note>
  Processing location depends on the endpoint you call and is subject to failover. Storage location is governed by your [Data Locality](/docs/account-setup/data-locality) setting and is not affected by the endpoint you call. See [Processing vs. storage](#processing-vs-storage) below.
</Note>

## 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](/docs/account-setup/data-locality) setting and, for AI products, the `region` request parameter.

| Endpoint | Region | Primary processing site |
| - | - | - |
| `api.telnyx.com` | North America | United States (Ashburn, Chicago, San Jose) |
| `api.telnyx.eu` | Europe | Frankfurt, Germany |
| `api.telnyx.com.au` | APAC | Sydney, Australia |
| `api.telnyx.ca` | Canada | Toronto |
| `api.telnyx.me` | Middle East | Dubai, UAE |

All endpoints serve the same REST API surface under `/v2`. Product availability varies by region — see [Product availability](#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:

| Control | What it governs | How to set it |
| - | - | - |
| **Regional endpoint** (in transit) | Where the request is received and processed | The base URL of each API request |
| **Data Locality** (at rest) | Where records and stored data (CDRs, MDRs, recordings, transcripts) are kept | [Data Locality](/docs/account-setup/data-locality) setting in the Mission Control Portal — an account-level, one-time, irreversible choice |

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](/docs/account-setup/data-locality)–governed data) are stored in the EU. The storage guarantee is contractual; the processing routing is subject to failover.

<Warning>
  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](/docs/inference/data-residency).
</Warning>

## 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:

<CodeGroup>
  ```bash curl theme={null}
  curl -X POST https://api.telnyx.eu/v2/messages \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $TELNYX_API_KEY" \
    -d '{
      "from": "+353000000000",
      "to": "+353000000001",
      "text": "This message was sent through the Frankfurt PoP."
    }'
  ```

  ```python Python theme={null}
  import os
  from telnyx import Telnyx

  client = Telnyx(
      api_key=os.environ.get("TELNYX_API_KEY"),
      base_url="https://api.telnyx.eu/v2",
  )

  response = client.messages.send(
      from_="+353000000000",
      to="+353000000001",
      text="This message was sent through the Frankfurt PoP.",
  )

  print(response.data.id)
  ```

  ```javascript Node theme={null}
  import Telnyx from 'telnyx';

  const client = new Telnyx({
    apiKey: process.env.TELNYX_API_KEY,
    baseURL: 'https://api.telnyx.eu/v2',
  });

  const response = await client.messages.send({
    from: '+353000000000',
    to: '+353000000001',
    text: 'This message was sent through the Frankfurt PoP.',
  });

  console.log(response.data.id);
  ```

  ```ruby Ruby theme={null}
  require "telnyx"

  client = Telnyx::Client.new(
    api_key: ENV["TELNYX_API_KEY"],
    base_url: "https://api.telnyx.eu/v2"
  )

  response = client.messages.send_(
    from: "+353000000000",
    to: "+353000000001",
    text: "This message was sent through the Frankfurt PoP."
  )

  puts response.data.id
  ```

  ```go Go theme={null}
  package main

  import (
    "context"
    "fmt"
    "os"

    "github.com/team-telnyx/telnyx-go"
    "github.com/team-telnyx/telnyx-go/option"
  )

  func main() {
    client := telnyx.NewClient(
      option.WithAPIKey(os.Getenv("TELNYX_API_KEY")),
      option.WithBaseURL("https://api.telnyx.eu/v2"),
    )
    response, err := client.Messages.Send(context.TODO(), telnyx.MessageSendParams{
      From: "+353000000000",
      To:   "+353000000001",
      Text: "This message was sent through the Frankfurt PoP.",
    })
    if err != nil {
      panic(err.Error())
    }
    fmt.Println(response.Data.ID)
  }
  ```

  ```java Java theme={null}
  package com.telnyx.example;

  import com.telnyx.sdk.client.TelnyxClient;
  import com.telnyx.sdk.client.okhttp.TelnyxOkHttpClient;
  import com.telnyx.sdk.models.messages.MessageSendParams;
  import com.telnyx.sdk.models.messages.MessageSendResponse;

  public final class Main {
      public static void main(String[] args) {
          TelnyxClient client = TelnyxOkHttpClient.builder()
              .apiKey(System.getenv("TELNYX_API_KEY"))
              .baseUrl("https://api.telnyx.eu/v2")
              .build();

          MessageSendParams params = MessageSendParams.builder()
              .from("+353000000000")
              .to("+353000000001")
              .text("This message was sent through the Frankfurt PoP.")
              .build();

          MessageSendResponse response = client.messages().send(params);
          System.out.println(response);
      }
  }
  ```

  ```csharp .NET theme={null}
  using Telnyx;

  TelnyxConfiguration.SetApiKey(Environment.GetEnvironmentVariable("TELNYX_API_KEY"));
  TelnyxConfiguration.SetApiBase("https://api.telnyx.eu/v2");

  var service = new MessageService();
  var response = await service.SendAsync(new MessageSendOptions
  {
      From = "+353000000000",
      To = "+353000000001",
      Text = "This message was sent through the Frankfurt PoP."
  });

  Console.WriteLine(response.Data);
  ```

  ```php PHP theme={null}
  <?php
  require_once 'vendor/autoload.php';

  use Telnyx\Client;

  $client = new Client(
    apiKey: getenv('TELNYX_API_KEY'),
    baseUrl: 'https://api.telnyx.eu/v2'
  );

  $response = $client->messages->send(
    from: '+353000000000',
    to: '+353000000001',
    text: 'This message was sent through the Frankfurt PoP.'
  );

  var_dump($response);
  ```
</CodeGroup>

<Note>
  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).
</Note>

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](/docs/voice/programmable-voice/voice-api-services-in-europe) and [AnchorSite Configuration](/docs/voice/sip-trunking/routing/anchorsite-configuration).

## Message flow through the EU PoP

An outbound SMS sent to `api.telnyx.eu` takes this path:

```mermaid theme={null}
graph LR
    A["Your application"] -->|"HTTPS POST /v2/messages"| B["Cloudflare edge"]
    B --> C["EU API gateway (Frankfurt)"]
    C --> D["messaging-outbound (Frankfurt)"]
    D --> E["Number pool and profile lookup"]
    E --> F["Kannel SMSC aggregation (Frankfurt)"]
    F --> G["Carrier / SMPP vendor"]
    G --> H["Recipient handset"]
    D --> I["MDR written to storage region (per Data Locality)"]
```

* 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](#processing-vs-storage).
* The Message Detail Record (MDR) is written to the storage region governed by the account's [Data Locality](/docs/account-setup/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.

| Product | `api.telnyx.eu` behavior |
| - | - |
| SMS / MMS (Messages API) | Supported. Requests are processed by messaging services in the Frankfurt region. |
| Voice API / Call Control | Supported. Set the application's AnchorSite® to an EU site. Conferences and queues cannot span regions. |
| TeXML | Supported via EU media sites. |
| Inference (AI) | Supported. EU GPU region (Paris); per-request pinning available with `region` + `mode: "strict"`. See [Data Residency](/docs/inference/data-residency). |
| WhatsApp | Not regionally deployed. WhatsApp API requests sent to any regional endpoint are processed by the US WhatsApp service. |
| Data Locality–governed storage | Governed by your Data Locality setting, not by the endpoint you call. See [Data Locality](/docs/account-setup/data-locality). |

<Warning>
  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.
</Warning>

## 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](/docs/development/api-fundamentals/reliability/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](#processing-vs-storage)).
* **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](/docs/account-setup/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).

<Warning>
  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.
</Warning>

## Related pages

* [Data Locality](/docs/account-setup/data-locality) — storage at rest, covered data types, region selection
* [Inference: Data Residency, Processing & Compliance FAQ](/docs/inference/data-residency) — AI-specific processing and storage
* [Voice API Services in Europe](/docs/voice/programmable-voice/voice-api-services-in-europe) — Voice API and AnchorSite® in the EU
* [AnchorSite Configuration](/docs/voice/sip-trunking/routing/anchorsite-configuration) — PoP selection for SIP calls
* [API rate limiting](/docs/development/api-fundamentals/reliability/rate-limiting) — rate-limit headers and recovery
* [Data privacy](https://telnyx.com/data-privacy) — Telnyx privacy practices