Migration guide

How to migrate from Rule to Vonage

A developer's guide to migrating SMS and RCS sending from Rule to Vonage, covering channel changes, request-format mapping, and a step-by-step cutover checklist.

Rule is a Swedish marketing-automation platform (Rule Communication Nordic AB) whose REST API sends transactional SMS, RCS and email. Vonage is a dedicated communications-API provider (part of Ericsson) covering SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger and voice. On the messaging.dev Score they sit far apart — Rule at 28/100 and Vonage at 89/100 — so this guide is a factual map of what changes when you move, not an endorsement.

What you gain and what you lose

Both providers keep you on SMS and RCS, and neither offers Telegram or Apple Messages for Business. The channel changes are otherwise substantial.

By moving to Vonage you gain MMS, WhatsApp, Viber, Facebook Messenger and voice. You lose email: Rule supports email, Vonage does not, so any email flows must stay on Rule or move to another service.

Other differences worth planning around:

  • Compliance: both are GDPR-aligned. Vonage adds ISO 27001, SOC 2 and HIPAA, none of which Rule lists.
  • Data residency: Rule runs EU servers only, with no region choice. Vonage offers EU and US servers, a data-residency choice, plus APAC and Australia regions — you gain flexibility but should explicitly select EU if EU-only processing matters to you.
  • Pricing model: Rule bills subscription tiers by contact-list size (from €595/month for 2,500 contacts, or a standalone SMS/RCS plan at €100/month) plus per-message fees. Vonage is pay-as-you-go per message/minute with volume discounts — no contact-list subscription.
  • Free credit: Rule offers none; Vonage includes €2 trial credit.
  • SDKs: Rule ships Node.js and PHP. Vonage adds Python, Java, C#, Ruby and Kotlin.
  • Sandbox & docs: Rule has no sandbox and medium-rated docs. Vonage provides a sandbox and high-rated docs.

Both expose REST APIs, so the transport model is familiar.

How the request format differs

Rule (source):

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

Vonage (target):

curl -X POST 'https://rest.nexmo.com/sms/json' \
  -d 'api_key=YOUR_API_KEY' \
  -d 'api_secret=YOUR_API_SECRET' \
  -d 'from=Vonage' \
  -d 'to=15551234567' \
  -d 'text=Hello from Vonage'

Endpoint: you move from https://app.rule.io/api/v2/transactionals to Vonage’s https://rest.nexmo.com/sms/json (legacy SMS API) or https://api.nexmo.com/v1/messages (Messages API).

Authentication: Rule authenticates with a single API key as a Bearer token in the Authorization header. Vonage’s SMS API uses an API Key + API Secret passed as request parameters; the Messages API uses JWT auth instead. That is two credentials rather than one, and (on the SMS API) they travel in the body, not a header.

Payload mapping: Rule sends JSON; the Vonage SMS API takes form-encoded fields. Map them as follows — sender from.namefrom; recipient to.phone_numberto; body contenttext. Rule’s transaction_type and sendout_type fields have no equivalent and are dropped. Note the recipient format: Rule uses +46... (E.164 with +), while the Vonage example uses a bare 15551234567.

Migration checklist

  1. Create a Vonage account and generate your API Key + API Secret (or a JWT/application for the Messages API).
  2. Map each request field per the table above and drop Rule-only fields.
  3. Re-point your sending code to the new endpoint and swap Bearer-token auth for key/secret or JWT.
  4. Re-test against Vonage’s sandbox — it has one — before sending live traffic.
  5. Update delivery/status webhooks to Vonage’s callback format.
  6. Run Rule and Vonage in parallel, comparing delivery results.
  7. Cut over once Vonage matches or exceeds your baseline, and decommission the Rule path.

For a from-scratch setup, see how to start with Vonage, and the full Rule vs Vonage comparison.

Watch out for

  • Email goes away. Vonage has no email channel; keep Rule or another provider for email.
  • Pricing shifts to per-message. Budgeting moves from contact-list subscriptions to pay-as-you-go usage.
  • Two API surfaces, two auth models. Decide up front between the SMS API (key/secret) and the Messages API (JWT).
  • Data residency is a choice, not a default. Vonage can route through US or other regions, so set EU explicitly if you relied on Rule’s EU-only processing.