How to migrate from CM.com to Twilio

CM.com is a conversational commerce and customer engagement platform offering business messaging across SMS, RCS, WhatsApp and other channels, plus voice, email and payments through APIs and cloud apps. Twilio is a customer engagement platform built around communications APIs for SMS, voice, email and more. On the messaging.dev Score, CM.com rates 58/100 and Twilio 88/100 — this guide covers what that gap means in practice when you re-point your sending code.

What you gain and what you lose

Channels. Both providers carry SMS, RCS, WhatsApp, voice and email, so your core traffic moves over unchanged. On Twilio you gain MMS. You lose four channels that CM.com supports and Twilio does not: Viber, Facebook Messenger, Telegram and Apple Messages for Business. If you send on any of those today, plan to keep CM.com (or another provider) in parallel for them.

Compliance. Both hold GDPR and ISO 27001. Twilio additionally lists SOC 2 and HIPAA, which CM.com’s dataset entry does not — relevant if you handle regulated data such as healthcare.

Data residency. CM.com hosts in the EU only, with no region choice. Twilio offers US and EU servers plus Australia and lets you choose data residency. You gain flexibility, but if EU-only residency was a hard requirement, you must explicitly select Twilio’s EU region rather than rely on a default.

Pricing and credit. Both bill pay-per-use. CM.com uses one fixed price per destination country with volume discounts above ~50,000 messages/month and optional subscription tiers; its per-country pricing isn’t published. Twilio publishes a starting price of $0.0079 per US SMS segment (plus carrier fees) with volume and committed-use discounts, and includes a $15 trial credit. CM.com offers no free developer credit.

Tooling. Both provide high-quality docs, a sandbox, and REST APIs. The common SDKs (Node.js, Python, PHP, Java) exist on both sides; Twilio also ships C#, Ruby and Go. One protocol difference: CM.com offers SMPP binding, whereas Twilio’s second API type is SMTP.

How the request format differs

Source (CM.com):

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"
      }]
    }
  }'

Target (Twilio):

curl -X POST 'https://api.twilio.com/2010-04-01/Accounts/ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/Messages.json' \
  --data-urlencode 'To=+15551234567' \
  --data-urlencode 'From=+15005550006' \
  --data-urlencode 'Body=Hello from Twilio' \
  -u ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_auth_token

Three things change:

• Endpoint. CM.com posts to a single fixed URL, https://gw.messaging.cm.com/v1.0/message. Twilio’s URL embeds your Account SID: https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json — build it per account.
• Authentication. CM.com authenticates with a product token in the X-CM-PRODUCTTOKEN header (TLS 1.2+ required). Twilio uses HTTP Basic auth — Account SID as username, Auth Token as password (the -u flag).
• Payload. CM.com takes a JSON body with a nested messages.msg[] array: recipient is to[].number, sender is from, and text is body.content. Twilio takes flat form-urlencoded fields: To, From, Body. So from → From, to[].number → To, body.content → Body, and you drop the JSON wrapper and CM.com’s reference field. Also switch recipient formatting to E.164 with a leading + (Twilio’s +15551234567) rather than CM.com’s 00-prefixed 00447911123456.

Migration checklist

1. Create a Twilio account and copy your Account SID and Auth Token from the dashboard (the $15 trial credit covers test sends).
2. Map the request fields: from → From, to[].number → To, body.content → Body, and drop the messages.msg[] wrapper.
3. Re-point your sending code to the Twilio endpoint and switch auth from the X-CM-PRODUCTTOKEN header to HTTP Basic (-u SID:token).
4. Re-test in Twilio’s sandbox before sending live traffic.
5. Update delivery webhooks and status callbacks to Twilio’s format.
6. Run both providers in parallel and compare delivery before you commit.
7. Cut over, keeping CM.com only for any Viber, Messenger, Telegram or Apple channels you still need.

Watch out for

• Lost channels. Viber, Facebook Messenger, Telegram and Apple Messages for Business are not available on Twilio.
• No SMPP. If you bind over SMPP to CM.com, Twilio’s dataset lists REST and SMTP only.
• Residency default. Twilio can host in the EU, but you must select it — its default is not EU-only as CM.com’s is.
• Formatting and encoding. E.164 numbers plus form-encoded fields instead of nested JSON will break a naive copy-paste.

For a full walkthrough of the target, see how to start with Twilio, or the side-by-side CM.com vs Twilio comparison.