How to migrate from Rule to Twilio
A developer-focused guide to moving transactional messaging from Rule to Twilio: channel and compliance differences, request-format mapping, and a step-by-step migration checklist.
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. Twilio is a US-based customer-engagement platform that exposes communications APIs across SMS, voice, email and more. On the messaging.dev Score, Rule rates 28/100 and Twilio 88/100; this guide covers what changes, as data, when you move your sending code from one to the other.
What changes when you move
Channels. Every channel you use on Rule — SMS, RCS and email — also exists on Twilio, so you lose no channels in the move. You additionally gain MMS, WhatsApp and voice, none of which Rule offers. Neither provider supports Viber, Facebook Messenger, Telegram or Apple Messages for Business.
Compliance. Rule is GDPR-aligned. Twilio is GDPR-aligned and adds ISO 27001, SOC 2 and HIPAA, so you keep every certification you had and gain three more.
Data residency. Rule runs on EU servers only, with no region choice. Twilio offers EU and US regions (plus Australia) and lets you choose your data residency — which also means US processing is possible unless you actively select the EU region.
Pricing and credit. Rule bills on subscription tiers by contact-list size (e.g. a standalone SMS/RCS plan at €100/month, Professional from €595/month) plus per-message fees from €0.04 per SMS. Twilio is pay-as-you-go per message/minute, from $0.0079 per US SMS segment plus carrier fees, and includes $15 trial credit; Rule has no free developer credit.
Tooling. Rule ships Node.js and PHP SDKs; Twilio ships Node.js, Python, PHP, Java, C#, Ruby and Go. Twilio provides a sandbox test environment (Rule has none), documentation rated high (Rule: medium), and both REST and SMTP APIs (Rule is REST-only). For a full setup walkthrough, see how to start with Twilio.
How the request format differs
Rule quickstart:
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!"
}'
Twilio quickstart:
curl -X POST 'https://api.twilio.com/2010-04-01/Accounts/ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/Messages.json' \
--data-urlencode 'To=+15551234567' \
--data-urlencode 'From=+15005550006' \
--data-urlencode 'Body=Hello from Twilio' \
-u ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:your_auth_token
Three things change:
- Endpoint / base URL. Rule posts to
https://app.rule.io/api/v2/transactionals. Twilio posts tohttps://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json, with your Account SID embedded in the URL path. - Authentication. Rule sends the API key as a Bearer token in the
Authorizationheader. Twilio uses HTTP Basic auth — Account SID as username, Auth Token as password (the-uflag). - Payload mapping. Rule sends a JSON body; Twilio sends form-encoded fields. Map recipient
to.phone_number→To, senderfrom.name→From, and bodycontent→Body. Rule’stransaction_typeandsendout_typehave no equivalent in Twilio’s basic send. Note the sender changes shape: Rule accepts an alphanumeric name, while Twilio’sFromis a phone number.
Migration checklist
- Create a Twilio account and copy your Account SID and Auth Token from the dashboard ($15 trial credit is included).
- Provision a Twilio sender — buy or verify the phone number you will use as
From, since Rule’s alphanumeric sender name no longer applies. - Map the request fields:
to.phone_number→To,from.name→From,content→Body; droptransaction_type/sendout_type. - Swap authentication: replace the Bearer header with Basic auth (
-u AccountSid:AuthToken), and switch the body from JSON to form-encoded. - Re-point your sending code to the new
Messages.jsonendpoint. - Re-test in Twilio’s sandbox before sending live traffic (Rule had no sandbox).
- Update webhooks and delivery callbacks to Twilio’s status-callback format.
- Run both providers in parallel, compare delivery, then cut over and decommission Rule.
Watch out for
- Data residency. Twilio is US-headquartered and can process in the US; if EU-only handling mattered under Rule (EU servers, no choice), explicitly select Twilio’s EU region.
- Pricing model. You move from predictable monthly subscription tiers in EUR to per-message pay-as-you-go in USD plus carrier fees — re-model your costs before cutover.
- Sender format. Rule accepted an alphanumeric sender name; Twilio’s
Frommust be a number you provision. - Request shape. JSON plus Bearer becomes form-encoded plus Basic auth — mechanical, but easy to miss.
For a full side-by-side, see the Rule vs Twilio comparison.