How to migrate from Rule to Bird

Rule is a Swedish marketing automation platform (Rule Communication Nordic AB) built around email, SMS and RCS campaigns with a REST API for transactional sends. Bird (formerly MessageBird) is a communications infrastructure platform offering unified APIs for email, SMS, WhatsApp and voice on a network that carries a large share of global commercial SMS. On the messaging.dev Score, Rule rates 28/100 and Bird 76/100 — a gap driven mostly by channels, certifications, tooling and data-residency options. This guide maps the concrete differences and walks through the migration.

What changes when you move

Channels. Both providers send SMS and email, so those carry over directly. Moving to Bird you gain WhatsApp and voice, and you lose RCS — Rule supports RCS, Bird does not, so any RCS traffic must fall back to SMS or another channel. Neither provider offers MMS, Viber, Facebook Messenger, Telegram or Apple Messages for Business, so nothing changes there.

Compliance. Both are GDPR-aligned. Bird adds ISO 27001, SOC 2 and HIPAA, none of which Rule lists — you gain certifications and lose none.

Data residency. Rule runs on EU servers only, with no region choice. Bird offers both EU and US servers with a data-residency choice, selected via the region-prefixed API key (see below).

Pricing model. Rule uses subscription tiers by contact-list size (plus per-message SMS/RCS fees), from around €0.04 per SMS on top of a monthly plan. Bird uses usage-based transactional pricing with no platform or seat fees, from $0.0073 per US SMS. If you only send transactional messages, this removes the fixed monthly floor.

Free credit, SDKs, sandbox, docs. Rule offers no free developer credit; Bird includes a free email tier (1,000/month). Rule ships Node.js and PHP SDKs; Bird ships TypeScript, Python and Go — Node.js/TypeScript overlaps, but PHP is not covered. Rule has no sandbox; Bird provides a test environment. Bird’s docs are rated high versus Rule’s medium, and Bird exposes both REST and SMTP where Rule is REST-only. See how to start with Bird for the full onboarding path, or the Bird vs Rule comparison for the side-by-side.

How the request format differs

Rule:

curl -X POST "https://app.rule.io/api/v2/transactionals" \
  -H "Authorization: Bearer YOUR-API-KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_type": "text_message",
    "sendout_type": "transactional",
    "from": {"name": "Rule"},
    "to": {"phone_number": "+46123456789"},
    "content": "Hello, world!"
  }'

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

Endpoint / base URL. Rule posts to https://app.rule.io/api/v2/transactionals. Bird posts to a region-prefixed host, https://us1.platform.bird.com/v1/sms/messages (or eu1).

Authentication. Both use a Bearer token in the Authorization header. Rule accepts a plain API key (also allowed as an apikey query parameter or body field). Bird’s key is region-prefixed (bk_us1_... / bk_eu1_...); the prefix encodes the regional host and SDKs route to it automatically.

Payload mapping. Flatten the nested Rule objects: recipient to.phone_number → to (a plain string); sender from.name → from (a plain string); message body content → text. Drop Rule’s transaction_type and sendout_type; Bird instead uses a category field (e.g. authentication).

Migration checklist

1. Create a Bird account and self-onboard; the free email tier lets you test at no cost.
2. Provision an API key in the region you need — bk_eu1_ for EU residency, bk_us1_ for US — and point requests at the matching host.
3. Map the request fields: to.phone_number → to, from.name → from, content → text; remove transaction_type/sendout_type and add category.
4. Re-point your sending code to the Bird base URL and swap the Node.js/PHP SDK for TypeScript, Python or Go (or call REST directly if you were on PHP).
5. Re-test in Bird’s sandbox before sending live traffic — Rule had none, so this is a new safety net.
6. Update webhooks / delivery callbacks to Bird’s format and endpoints.
7. Run both in parallel, comparing delivery on real traffic, then cut over once Bird matches your baseline.

Watch out for

• RCS disappears. Rule supports RCS; Bird does not. Plan a fallback for any RCS sends before you cut over.
• No PHP SDK. If you integrated Rule via its PHP SDK, Bird offers only TypeScript, Python and Go — you’ll call REST directly.
• Region-bound keys. A bk_us1_ key only reaches the US host; for EU data residency you must issue a bk_eu1_ key and use the eu1 host.
• Free credit is email-only. Bird’s free tier covers 1,000 emails/month; there’s no free SMS allowance, so SMS testing bills from $0.0073 per message.