How to migrate from CM.com to Sinch

CM.com is a conversational-commerce and customer-engagement platform based in Breda, Netherlands, offering business messaging across SMS, RCS, WhatsApp and other channels, plus voice, email and payments. Sinch is a Stockholm-based cloud-communications platform providing messaging, voice and email APIs. On the messaging.dev Score, CM.com rates 58/100 and Sinch rates 92/100; this guide covers the concrete API and capability differences you will hit when moving between them.

What you gain and lose

Channels. Both providers cover the same core set: SMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, Apple Messages for Business, voice and email. You lose no channels in this move. The one channel you gain is MMS, which Sinch supports and CM.com does not.

Compliance and residency. Both hold GDPR and ISO 27001. Sinch additionally reports SOC 2 and HIPAA. On data residency, CM.com hosts in the EU only with no region choice; Sinch offers EU and US servers plus APAC, Australia and Brazil, and lets you choose your residency region.

Pricing and credit. Both bill pay-as-you-go per message. CM.com uses one fixed price per destination country with volume discounts above roughly 50,000 messages/month and optional subscription tiers; Sinch adds committed-use pricing and publishes an indicative ~$0.0075 per US SMS segment (plus carrier fees). Sinch includes free trial credit for new accounts; CM.com does not.

Tooling. Docs quality is high on both, and both provide a sandbox test environment. SDK coverage overlaps on Java, Python, Node.js and PHP; CM.com additionally lists .NET while Sinch lists C# (the same ecosystem). Sinch’s API surface adds SMTP alongside the REST and SMPP both share, and it publishes a 99.95% uptime SLA where CM.com publishes none. For a full walkthrough of the destination, see how to start with Sinch; for a side-by-side, see CM.com vs Sinch.

How the request format differs

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

Sinch:

curl -X POST 'https://us.sms.api.sinch.com/xms/v1/YOUR_SERVICE_PLAN_ID/batches' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"from":"+15005550006","to":["+15551234567"],"body":"Hello from Sinch"}'

Endpoint. CM.com posts every message to one static endpoint, https://gw.messaging.cm.com/v1.0/message. Sinch posts to a region-specific host with your service plan ID baked into the path: https://us.sms.api.sinch.com/xms/v1/{service_plan_id}/batches. That service plan ID is per-account and must be substituted at runtime.

Authentication. CM.com authenticates with a product token in the custom X-CM-PRODUCTTOKEN header. Sinch uses a standard Bearer token in the Authorization header. Swap both the header name and the scheme.

Payload mapping. CM.com wraps messages in a messages.msg[] envelope; Sinch posts a flat batch object. The sender field is from in both. The recipient list is to in both, but CM.com expects an array of objects ([{"number": "..."}]) while Sinch expects an array of plain E.164 strings (["+15551234567"]). The message body is a nested object with type and content in CM.com, versus a plain string in Sinch. CM.com’s optional reference has no direct equivalent in the minimal Sinch batch.

Migration checklist

1. Create a Sinch account, generate an API token, and note your service plan ID.
2. Choose your region/host and data residency (the quickstart defaults to the US host).
3. Map request fields: to becomes an array of E.164 strings, from stays, body becomes a plain string, and the messages.msg[] envelope is dropped.
4. Swap authentication: replace X-CM-PRODUCTTOKEN with Authorization: Bearer.
5. Re-point your sending code to the Sinch /batches endpoint.
6. Re-test against Sinch’s sandbox (both providers have one) before sending live traffic.
7. Update webhooks and delivery callbacks to Sinch’s callback format.
8. Run both providers in parallel and reconcile delivery receipts.
9. Cut over once parity holds, then retire the CM.com credentials.

Watch out for

• Residency is not automatic. The quickstart uses the US host (us.sms.api.sinch.com). To keep the EU-only footprint you had on CM.com, select an EU region/service plan; Sinch offers the choice but does not default to it.
• Recipient shape changes. CM.com’s {"number": "..."} objects and 00-prefixed numbers must become plain +E.164 strings, or messages fail validation.
• Service plan ID lives in the URL, not the body, which is a common misconfiguration when porting code.
• G2 rating context. Sinch averages 4.3 across 150 reviews versus CM.com’s 4.8 across 12, so weigh the larger sample when setting expectations.