Migration guide

How to migrate from GMS to Telnyx

A developer guide to migrating messaging from GMS to Telnyx: channel and compliance differences, request-format mapping, and a step-by-step cutover checklist.

GMS is an enterprise CPaaS and A2P messaging provider based in Switzerland that offers SMS, RCS, WhatsApp, Viber and email through a single API. Telnyx is a licensed telecom carrier running a CPaaS platform for SMS, MMS, RCS, WhatsApp, voice and email over its own private global IP network. On the messaging.dev Score, GMS rates 36/100 and Telnyx 78/100; this guide covers what actually changes at the API level when you migrate.

What changes when you move

Channels. Both providers cover SMS, RCS, WhatsApp and email. Moving to Telnyx you gain MMS and voice, and you lose Viber — GMS supports Viber, Telnyx does not. Neither provider offers Facebook Messenger, Telegram or Apple Messages for Business.

Compliance. Both hold GDPR and ISO 27001. Telnyx additionally carries SOC 2 and HIPAA, which GMS does not.

Data residency. GMS runs EU servers only, with no region choice. Telnyx runs both US and EU servers, adds Asia-Pacific and South America, and lets you choose your data residency region.

Pricing. GMS uses custom enterprise pricing negotiated with sales, with no public price list. Telnyx is pay-as-you-go, billed per message part, from $0.004 per outbound SMS part in the US (plus carrier fees), with volume discounts and custom contracts at high volume.

Onboarding and tooling. GMS onboarding is not self-service (activation may require a call); Telnyx is self-service, so you can provision keys immediately. Telnyx ships server-side SDKs (Node.js, Python, Ruby, Go, Java, .NET, PHP) versus GMS’s mobile-only iOS (Swift) and Android (Kotlin) SDKs, its docs rate high versus GMS’s medium, and it exposes SMPP alongside REST. Neither provider offers a sandbox or a free developer credit. For a field-by-field view, see the GMS vs Telnyx comparison.

How the request format differs

GMS quickstart:

curl -X POST 'https://api-v2.hyber.im/{client_id}' \
  -u 'CLIENT_ID:API_PASSWORD' \
  -H 'Content-Type: application/json' \
  -d '{
    "phone": "380631010100",
    "channels": ["sms"],
    "sms": {
      "sender": "MyBrand",
      "text": "Hello from GMS",
      "ttl": 300
    }
  }'

Telnyx quickstart:

curl -X POST https://api.telnyx.com/v2/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "from": "+15551234567",
    "to": "+15559876543",
    "text": "Hello, world!"
  }'

Three things change. The endpoint moves from https://api-v2.hyber.im/{client_id}, which embeds your client ID in the path, to the single fixed https://api.telnyx.com/v2/messages. The authentication moves from HTTP Basic — a base64-encoded client_id:password passed via -u — to a Bearer API key in the Authorization header. The payload flattens: GMS nests channel data, using a top-level phone for the recipient, a channels array, and an sms object that holds sender, text and ttl. Telnyx is flat — to for the recipient, from for the sender, text for the body. Map phone to to, sms.sender to from, and sms.text to text; drop the channels array and the sms wrapper. The ttl field has no direct equivalent in the basic Telnyx send.

Migration checklist

  1. Create a Telnyx account and generate an API key — onboarding is self-service, no sales call. Follow the Telnyx quickstart.
  2. Provision a sender (a number or sender ID) to populate the from field, since Telnyx sends require an explicit sender.
  3. Map the request fields: phone to to, sms.sender to from, sms.text to text; flatten the payload, swap Basic auth for the Bearer key, and point at https://api.telnyx.com/v2/messages.
  4. Re-point your sending code at the new base URL, and adopt a Telnyx server SDK if you were previously hand-rolling requests.
  5. Update delivery webhooks and callbacks to consume Telnyx’s status format instead of the GMS one.
  6. Re-test. Telnyx has no sandbox, so your first sends hit production — throttle them and send to a controlled test number.
  7. Run both providers in parallel and compare delivery before switching all traffic.
  8. Cut over and decommission the GMS integration.

Watch out for

  • No Viber channel. If any GMS traffic uses Viber, Telnyx has no Viber support — re-route that traffic to SMS, WhatsApp or RCS, or keep a separate provider for it.
  • No sandbox. With sandbox unavailable, your first tests run against live production; guard them with low volume and a known test number.
  • No free developer credit. You will need to fund the account before testing.
  • Per-part billing. Telnyx bills per message part, so long or Unicode messages that split into multiple parts each cost extra — model this against GMS’s negotiated flat enterprise pricing.