Migration guide

How to migrate from CM.com to Bird

A developer's guide to moving messaging traffic from CM.com to Bird: channel and compliance differences, request-format mapping, and a step-by-step migration checklist.

CM.com is a conversational-commerce and customer-engagement platform that spans SMS, RCS, WhatsApp and several other channels plus voice and email. Bird (formerly MessageBird) is a communications-infrastructure platform offering unified APIs for email, SMS, WhatsApp and voice. On the messaging.dev Score, CM.com rates 58/100 and Bird 76/100; this guide covers what actually changes at the API and capability level when you migrate.

What changes when you move

Channels. Both providers cover SMS, WhatsApp, voice and email, and neither offers MMS. Moving to Bird you lose five channels CM.com supports: RCS, Viber, Facebook Messenger, Telegram and Apple Messages for Business. You gain no new channel — Bird’s channel set is a subset of CM.com’s.

Compliance. CM.com holds GDPR and ISO 27001. Bird holds those plus SOC 2 and HIPAA, so you lose no certification and gain two.

Data residency. CM.com hosts in the EU only, with no region choice. Bird offers both EU and US hosting and lets you choose data residency — the API key prefix encodes the region.

Pricing and credit. Both bill usage-based per message. CM.com’s per-country SMS starting price is not published; Bird publishes a per-country rate grid (from $0.0073 per message to US numbers, carrier fees extra) and adds a free email tier of 1,000 messages/month, whereas CM.com offers no free developer credit.

Tooling. Both ship high-quality docs and a sandbox. SDK coverage differs: CM.com offers PHP, Java, Python, .NET and Node.js; Bird offers TypeScript, Python and Go — only Python is common to both. On protocols, CM.com exposes REST and SMPP; Bird exposes REST and SMTP.

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

Bird quickstart:

curl -X POST "https://us1.platform.bird.com/v1/sms/messages" \
  -H "Authorization: Bearer bk_us1_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155550100",
    "from": "Bird",
    "text": "Your Bird verification code is 481920. It expires in 10 minutes.",
    "category": "authentication"
  }'

Endpoint. CM.com posts everything to one gateway URL, https://gw.messaging.cm.com/v1.0/message. Bird posts SMS to a region-prefixed host, https://us1.platform.bird.com/v1/sms/messages (or eu1...), and the host must match your key’s region.

Authentication. CM.com passes a product token in the X-CM-PRODUCTTOKEN header. Bird uses a region-prefixed API key (bk_us1_... / bk_eu1_...) as a Bearer token in the Authorization header. Swap the header name and scheme; TLS is required either way.

Payload mapping. CM.com wraps messages in messages.msg[], an array of message objects; Bird sends a single flat JSON object. Field by field:

  • Recipient: CM.com to is an array of objects [{"number": "00447911123456"}]; Bird to is a single E.164 string "+14155550100".
  • Sender: both call it from (a string).
  • Body: CM.com nests the text in body.content alongside a body.type; Bird uses a top-level text string.
  • Metadata: CM.com’s reference (your tracking id) has no direct equivalent in Bird’s quickstart, which instead expects a category (e.g. "authentication") classifying the message.

Migration checklist

  1. Create a Bird account and generate a region-prefixed API key (bk_us1_... or bk_eu1_...). Pick your data-residency region first — it is baked into both the key and the host. See how to start with Bird for the full walkthrough.
  2. Map the request fields: to array → string, body.contenttext, keep from, drop reference and add category.
  3. Re-point your sending code to the new base URL and swap X-CM-PRODUCTTOKEN for Authorization: Bearer. If you used a PHP, Java, .NET or Node.js SDK, move to TypeScript, Python or Go.
  4. Re-test in Bird’s sandbox (it has one) before sending live traffic.
  5. Update delivery/status webhooks to Bird’s callback format and endpoints.
  6. Run both providers in parallel and compare delivery rates.
  7. Cut over once results match.

Watch out for

  • Lost channels: RCS, Viber, Facebook Messenger, Telegram and Apple Messages for Business are not available on Bird — if you use any, keep them on a separate provider.
  • No SMPP: Bird offers REST and SMTP but not SMPP, so existing SMPP binds must be re-implemented over REST.
  • SDK gaps: no official PHP, Java, .NET or Node.js SDK; only TypeScript, Python and Go, with Python the sole overlap.
  • Region lock-in: the API key and host are region-specific, so choose EU vs US before generating keys.

For a full dimension-by-dimension breakdown, see the Bird vs CM.com comparison.