How to migrate from CM.com to Telnyx

CM.com is a conversational-commerce and customer-engagement platform based in Breda, Netherlands, that sends business messaging over SMS, RCS, WhatsApp and other channels plus voice and email. Telnyx is a licensed telecom carrier running a CPaaS platform on its own private global IP network, with APIs for SMS, MMS, RCS, WhatsApp, voice and email. On the messaging.dev Score, CM.com rates 58/100 and Telnyx 78/100. This guide covers what actually changes when you move an SMS integration from one to the other.

What changes when you move

Channels. Both platforms keep you covered on SMS, RCS, WhatsApp, voice and email. Moving to Telnyx you gain MMS, which CM.com does not offer. You lose four channels that CM.com supports and Telnyx does not: Viber, Facebook Messenger, Telegram and Apple Messages for Business. If any of those carry live traffic today, plan a replacement path before cutting over.

Compliance. Both hold GDPR and ISO 27001. Telnyx adds SOC 2 and HIPAA, so if you need either certification, this move is a step up rather than a compromise.

Data residency. CM.com hosts in the EU only, with no region choice. Telnyx offers US and EU servers plus Asia-Pacific and South America, and lets you choose your data residency region. You gain flexibility, but if an EU-only footprint is a contractual requirement, configure the region explicitly on Telnyx rather than assuming the default.

Pricing. CM.com uses pay-per-use with one fixed price per destination country (its starting price is not published). Telnyx is pay-as-you-go billed per message part, starting at $0.004 per outbound SMS part in the US plus carrier fees. Because Telnyx meters per segment, multi-part messages cost more than a naive per-message estimate — re-model your unit costs accordingly.

Everything else. Neither provider offers a free developer credit. Both ship high-quality docs and expose REST and SMPP. Telnyx’s SDK set is a superset of CM.com’s: both cover PHP, Java, Python, .NET and Node.js, and Telnyx adds Ruby and Go. Telnyx publishes a 99.99% uptime SLA; CM.com publishes none. The notable regression is testing: CM.com provides a sandbox, and Telnyx does not.

How the request format differs

CM.com quickstart:

curl -X POST https://gw.messaging.cm.com/v1.0/message \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  -H 'X-CM-PRODUCTTOKEN: <YOUR_PRODUCT_TOKEN>' \
  --data-raw '{
    "messages": {
      "msg": [{
        "from": "Sender",
        "to": [{"number": "00447911123456"}],
        "body": {"type": "auto", "content": "My first CM.com message"},
        "reference": "my_reference_123"
      }]
    }
  }'

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://gw.messaging.cm.com/v1.0/message to https://api.telnyx.com/v2/messages. The authentication changes from a product token in the custom X-CM-PRODUCTTOKEN header (obtained from CM.com’s Channels app) to a standard Authorization: Bearer YOUR_API_KEY header. The payload flattens: CM.com nests one or more messages under messages.msg[], sets the recipient as an array of objects (to: [{"number": ...}]), and puts the body under body.content with a type; Telnyx sends a single flat object where to is a plain E.164 string and the body is a top-level text field. Map from → from (note Telnyx expects a phone number rather than an alphanumeric sender ID), to[].number → to, and body.content → text. CM.com’s reference field has no direct equivalent in the minimal Telnyx call.

Migration checklist

1. Create a Telnyx account (self-onboarding) and generate an API key from the dashboard.
2. Store the key as a secret and swap the X-CM-PRODUCTTOKEN header for Authorization: Bearer.
3. Re-point your base URL to https://api.telnyx.com/v2/messages.
4. Rewrite the payload: flatten messages.msg[] to a single object and map from, to, and text as above.
5. Because Telnyx has no sandbox, test against live numbers you control, sending low-volume real traffic and checking for 2xx responses.
6. Update your delivery-receipt/webhook handling to Telnyx’s callback format.
7. Run both integrations in parallel, comparing delivery on the channels you keep.
8. Cut over once volumes and delivery rates match, then decommission the CM.com path.

For a fuller onboarding walkthrough, see how to start with Telnyx.

Watch out for

• No sandbox. CM.com’s test environment does not exist on Telnyx; validate with real, low-volume traffic.
• Four channels dropped. Viber, Facebook Messenger, Telegram and Apple Messages for Business are unavailable on Telnyx.
• Per-part billing. Long or Unicode messages split into segments and bill per part — re-check cost models.
• Sender format. Telnyx expects phone numbers where CM.com accepted alphanumeric sender IDs.

For a full side-by-side, see the CM.com vs Telnyx comparison.