How to migrate from Rule to Sinch

Rule is a Swedish marketing-automation platform (Rule Communication Nordic AB) that exposes a REST API for transactional SMS, RCS and email. Sinch is a cloud communications platform offering messaging, voice and email APIs across a wider set of channels. On the messaging.dev Score, Rule rates 28/100 and Sinch 92/100; this guide covers what actually changes at the account and code level when you move between them.

What changes when you move

Channels. This migration is additive. You keep SMS, RCS and email, and lose no channel. On top of those, Sinch adds MMS, WhatsApp, Viber, Facebook Messenger, Telegram, Apple Messages for Business and Voice.

Compliance and data residency. Both providers are GDPR-aligned and run EU servers. Sinch additionally holds ISO 27001, SOC 2 and HIPAA, and offers US servers plus a data-residency choice (with APAC, Australia and Brazil regions). Rule is EU-only with no region selection.

Pricing and free credit. The billing model changes. Rule sells subscription tiers by contact-list size plus per-message fees (from about €0.04 per SMS); Sinch is pay-as-you-go per message (approx. $0.0075 per US SMS segment) with volume and committed-use options, and includes free trial credit that Rule does not.

Tooling. Both ship Node.js and PHP SDKs over a REST API. Sinch adds Java, Python and C# SDKs, SMTP and SMPP access, a sandbox test environment (Rule has none), and rates “high” on docs quality against Rule’s “med”.

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

Sinch:

curl -X POST 'https://us.sms.api.sinch.com/xms/v1/YOUR_SERVICE_PLAN_ID/batches' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"from":"+15005550006","to":["+15551234567"],"body":"Hello from Sinch"}'

Endpoint / base URL. Rule posts to a fixed /api/v2/transactionals path. Sinch posts to /xms/v1/{service_plan_id}/batches, so you must template your service plan ID into the URL, and the host encodes the region (us. in the example).

Authentication. Both use a Bearer token in the Authorization header, so the mechanism carries over unchanged. Rule also accepts the key as an apikey query parameter or request-body field; Sinch expects the header.

Payload mapping. The recipient moves from Rule’s to.phone_number (a single string inside an object) to Sinch’s to (an array of strings — Sinch is batch-oriented). The sender moves from from.name (a name object) to from (a single string, a number). The message body moves from content to body. Rule’s transaction_type and sendout_type fields have no equivalent in this Sinch call and are dropped.

Migration checklist

1. Create a Sinch account (self-onboarding, free trial credit included) and generate an API token plus a service plan ID. See how to start with Sinch for the full walk-through.
2. Map the request fields: content → body, to.phone_number → the to array, from.name → the from sender string; drop transaction_type and sendout_type.
3. Re-point your sending code to the Sinch base URL with your service plan ID, keeping the Bearer Authorization header.
4. Re-test in Sinch’s sandbox before sending any live traffic.
5. Update delivery/webhook callbacks to Sinch’s delivery-report format.
6. Run both providers in parallel and reconcile delivery results.
7. Cut over once volumes match, then decommission Rule.

Watch out for

Because Sinch is a superset of Rule on the dimensions above, you do not lose any channel, certification, EU residency, sandbox, docs quality or free credit — the gotchas are mechanical rather than downgrades:

• Region. The quickstart uses the US endpoint (us.sms.api.sinch.com). Rule was EU-only; if you need EU data residency, select Sinch’s EU regional endpoint instead of the default US host.
• Sender identity. Rule accepted a name-based sender; the Sinch example uses a numeric sender. Confirm and register your sender ID format before cutover.
• Billing shift. You move from a monthly subscription priced by contact-list size to pure pay-as-you-go — re-model cost against your actual message volume.
• URL templating. The service plan ID lives in the URL path, not the body — a common first-call error.

For a dimension-by-dimension breakdown, see the Rule vs Sinch comparison.