Migration guide

How to migrate from GatewayAPI to Bird

A developer-focused, data-backed guide to moving your messaging integration from GatewayAPI to Bird, covering channel and compliance differences, request-format changes, and a step-by-step cutover checklist.

GatewayAPI is a Danish SMS gateway and messaging platform offering SMS, RCS and email APIs with EU data hosting. Bird (formerly MessageBird) is a larger communications-infrastructure platform whose unified APIs cover SMS, WhatsApp, voice and email. On the messaging.dev Score, GatewayAPI rates 54/100 and Bird 76/100 — this guide walks through what actually changes at the API level when you migrate, presented as data rather than a recommendation.

What changes when you move

Channels. Both providers send SMS and email, so those pipelines carry over unchanged. Moving to Bird you gain WhatsApp and voice, but you lose RCS — GatewayAPI supports RCS and Bird does not. Neither supports MMS, Viber, Facebook Messenger, Telegram or Apple Messages for Business, so nothing changes there.

Compliance. GatewayAPI is GDPR-aligned only. Bird is also GDPR-aligned and adds ISO 27001, SOC 2 and HIPAA, so regulated workloads that GatewayAPI could not attest for become viable.

Data residency. Both offer EU servers and a data-residency choice. Bird additionally runs US servers; GatewayAPI is EU-only.

Pricing and free credit. Both are usage-based with no platform or seat fees. GatewayAPI is pure pay-as-you-go on prepaid credit (from €0.0061/SMS) with test credits available on request. Bird publishes per-country per-message SMS rates (from $0.0073 to US numbers), prices WhatsApp by destination and category, and adds volume-tiered email subscriptions (a free 1,000-email/month tier, then e.g. $15/month for 50K emails). Note the shift from EUR to USD.

Tooling. This is where Bird pulls ahead for developers: it ships official TypeScript, Python and Go SDKs, a sandbox test environment, and documentation rated high quality. GatewayAPI ships no SDKs, has no sandbox, and its docs are rated medium — though it does expose SMPP and Email-to-SMS alongside REST, which Bird (REST/SMTP) does not.

How the request format differs

Source (GatewayAPI):

curl https://gatewayapi.com/rest/mtsms \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"sender": "ExampleSMS", "message": "Hello World", "recipients": [{"msisdn": 4512345678}]}'

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. You POST to a region-specific host, https://us1.platform.bird.com/v1/sms/messages, instead of https://gatewayapi.com/rest/mtsms (GatewayAPI’s EU-hosted accounts use gatewayapi.eu).
  • Authentication. GatewayAPI uses Authorization: Token YOUR_API_TOKEN. Bird uses a region-prefixed key as a Bearer token — Authorization: Bearer bk_us1_... — where the prefix (us1/eu1) encodes the host and the SDKs route automatically.
  • Payload. Bird’s body is flatter. GatewayAPI’s recipients array of { "msisdn": 4512345678 } objects (numeric, no +) becomes a single to string in E.164 format ("+14155550100"); sender becomes from; and message becomes text. Bird also expects a category field (e.g. "authentication") that has no GatewayAPI equivalent.

Migration checklist

  1. Create a Bird account, pick your region (us1/eu1) and generate the region-prefixed API key.
  2. Map the request fields: recipients[].msisdnto (E.164 with +), senderfrom, messagetext, and add category.
  3. Re-point your sending code to the Bird endpoint and swap the auth header from Token to Bearer. Optionally adopt an official SDK (TypeScript, Python or Go).
  4. Re-test in Bird’s sandbox before sending live traffic — GatewayAPI has none, so this is a new safety net.
  5. Update your delivery/webhook callbacks to consume Bird’s status payloads instead of GatewayAPI’s.
  6. Run both providers in parallel, comparing delivery and cost on real traffic.
  7. Cut over once Bird’s numbers match, then decommission the GatewayAPI credentials.

Watch out for

  • No RCS. If you send RCS today, Bird cannot replace it — keep GatewayAPI or another provider for that channel.
  • Fewer countries on paper. Bird’s dataset lists 150 countries covered versus GatewayAPI’s 200 — verify your destinations.
  • No SMPP. GatewayAPI offers SMPP and Email-to-SMS; Bird is REST/SMTP only, so any SMPP binding must be rebuilt over REST.
  • Free credit is email-only. Bird’s free tier covers 1,000 emails/month; there is no equivalent free SMS allowance, so SMS testing consumes paid credit unless you use the sandbox.
  • Longer data retention. Bird retains telecom metadata for 6 months (up to two years where local law requires) versus GatewayAPI’s 30-day anonymization and optional “secret” no-store message class.

For a deeper walkthrough of the target, see how to start with Bird, or the full Bird vs GatewayAPI comparison.