How to migrate from Telesign to Bird

Telesign is a digital identity and programmable communications platform offering SMS, RCS, voice, WhatsApp, Viber and email APIs alongside phone verification and fraud-prevention services. Bird (formerly MessageBird) is a communications infrastructure platform providing unified APIs for email, SMS, WhatsApp and voice. On the messaging.dev Score, Telesign rates 70/100 and Bird 76/100 — a six-point gap that this guide breaks down into concrete, developer-facing differences.

Channels you keep and lose

Both platforms carry SMS, WhatsApp, voice and email, and neither offers MMS, Facebook Messenger, Telegram or Apple Messages for Business. The move costs you two channels: RCS and Viber, both supported by Telesign but not by Bird. You gain no new channel in return. If any of your Telesign traffic runs over RCS or Viber, there is no Bird equivalent — you will need to keep those flows on another provider or retire them.

Compliance, data residency, pricing and tooling

Compliance is identical: both are GDPR, ISO 27001, SOC 2 and HIPAA aligned. Both run US and EU servers, but Bird adds explicit data-residency choice — the region-prefixed key (us1/eu1) pins traffic to a host — whereas Telesign does not expose region selection.

Pricing transparency differs. Telesign uses pay-as-you-go per-message pricing with volume-based enterprise contracts and does not publish per-message rates. Bird publishes a per-country SMS grid starting at $0.0073 per US message (carrier fees extra) plus volume-tiered email subscriptions. Both offer free developer credit, though Bird’s is specifically a free email tier (1,000/month) while Telesign provides general free trial credit.

SDK coverage narrows. Telesign ships C#, Java, Node.js, PHP, Python and Ruby; Bird ships TypeScript, Python and Go. Python is the only overlap, so C#, Java, PHP and Ruby integrations lose their official SDK. Bird does add a sandbox test environment (Telesign has none) and an SMTP interface for email alongside REST. Docs quality is high on both. See the Bird quickstart and the full Bird vs Telesign comparison.

How the request format differs

Source (Telesign):

curl -X POST https://rest-ww.telesign.com/v1/messaging \
  -u "CUSTOMER_ID:API_KEY" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "phone_number=15551212&message=Your message here.&message_type=ARN"

Target (Bird):

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

Three things change. Endpoint: Telesign posts to a single global host, https://rest-ww.telesign.com/v1/messaging; Bird posts to a region-prefixed host, https://us1.platform.bird.com/v1/sms/messages (swap us1 for eu1 to hit the EU region). Authentication: Telesign uses HTTP Basic — Customer ID as username, API key as password (Basic or Digest supported). Bird uses a Bearer token in the Authorization header, and the key prefix (bk_us1_/bk_eu1_) encodes the region, so your key choice also selects the host. Payload: the body shifts from application/x-www-form-urlencoded to JSON. The recipient field phone_number (bare digits) becomes to (E.164 with a leading +); the message body message becomes text; Telesign has no sender in the sample while Bird takes a from sender ID; and Telesign’s message_type classifier maps conceptually to Bird’s category, though the accepted values differ.

Migration checklist

1. Create a Bird account and generate a region-prefixed API key (bk_us1_... or bk_eu1_...) from the dashboard, choosing the region that matches your data-residency needs.
2. Map the request fields: phone_number → to (add the + and country code), message → text, add a from sender ID, and translate message_type to Bird’s category.
3. Re-point your sending code to https://us1.platform.bird.com/v1/sms/messages (or the eu1 host), switch auth from Basic to Bearer, and send a JSON body instead of form-encoded data.
4. Re-test against Bird’s sandbox before touching live traffic — Bird provides one, so validate payloads and error handling there.
5. Update delivery-status webhooks and callbacks to consume Bird’s response and event format.
6. Run Telesign and Bird in parallel, splitting a slice of traffic to compare delivery and latency.
7. Cut over once metrics match, then decommission the Telesign path (keeping any RCS/Viber flows elsewhere).

Watch out for

• Lost channels: RCS and Viber have no Bird equivalent — plan a fallback before you cut over.
• Fewer countries: Bird lists 150 countries covered versus Telesign’s 230; confirm your destinations are supported.
• Thinner SDK coverage: only Python carries over; C#, Java, PHP and Ruby callers move to raw REST or a community library.
• Regional key coupling: the key prefix binds you to us1 or eu1; sending to the wrong region means issuing a new key, not just changing a URL.