Migration guide

How to migrate from Rule to Telnyx

A developer-focused guide to moving transactional messaging from Rule to Telnyx: 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 for email, SMS, and RCS campaigns, with a REST API for transactional sends. Telnyx is a licensed telecom carrier running a CPaaS platform with APIs for SMS, MMS, RCS, WhatsApp, voice, and email over its own private global IP network. On the messaging.dev Score, Rule rates 28/100 and Telnyx 78/100 — this guide covers what actually changes at the code and account level when you move between them.

What you gain and what you lose

Channels. Rule sends SMS, RCS, and email. Telnyx sends all three plus MMS, WhatsApp, and voice. You lose no channel by migrating — every channel Rule offers also exists on Telnyx — and you gain MMS, WhatsApp, and voice on the same account. Neither provider offers Viber, Facebook Messenger, Telegram, or Apple Messages for Business.

Compliance. Both are GDPR-aligned. Telnyx additionally lists ISO 27001, SOC 2, and HIPAA; Rule lists none of these.

Data residency. Rule runs on EU servers only, with no region choice. Telnyx offers both EU and US servers, adds Asia-Pacific and South America, and lets you choose your data residency region.

Pricing. Rule bills subscription tiers by contact-list size (Professional from €595/month, or €100/month for the standalone SMS/RCS plan) plus per-message fees from €0.04/SMS. Telnyx is pure pay-as-you-go, billed per message part, from $0.004 per outbound SMS part — no monthly plan.

Tooling. Telnyx ships SDKs for Node.js, Python, Ruby, Go, Java, .NET, and PHP; Rule ships Node.js and PHP. Telnyx’s docs rate high against Rule’s med, and Telnyx exposes both REST and SMPP where Rule is REST-only. Neither offers a sandbox or free developer credit.

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

Telnyx quickstart:

curl -X POST https://api.telnyx.com/v2/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "from": "+15551234567",
    "to": "+15559876543",
    "text": "Hello, world!"
  }'

Endpoint. The base URL moves from https://app.rule.io/api/v2 (POST to /transactionals) to https://api.telnyx.com/v2/messages.

Authentication. Both use a Bearer API key in the Authorization header, so your auth code carries over almost unchanged. (Rule also accepts the key as an apikey query parameter or body field; Telnyx is Bearer-header only.)

Payload. The fields map but restructure:

  • Recipient: Rule’s nested to.phone_number becomes a flat string to.
  • Sender: Rule’s from.name object (an alphanumeric sender name) becomes a flat from string — a phone number or registered sender ID.
  • Body: content becomes text.
  • Rule’s transaction_type and sendout_type fields have no Telnyx equivalent; drop them.

Migration checklist

  1. Create a Telnyx account (onboarding is self-service) and generate an API key — see the Telnyx quickstart.
  2. Provision a sending number or register a sender ID for the from field.
  3. Map each request field: swap the endpoint, flatten to, convert from.name to a number/sender ID, rename content to text, and remove transaction_type/sendout_type.
  4. Re-point your sending code to https://api.telnyx.com/v2/messages and swap in the new key.
  5. Re-test. Telnyx has no sandbox, so validate against live credentials with a controlled test number and low volume.
  6. Update webhooks and delivery callbacks to consume Telnyx’s delivery-status payloads instead of Rule’s.
  7. Run both integrations in parallel, comparing delivery results.
  8. Cut over once parity holds, then decommission the Rule integration.

Watch out for

  • No sandbox on either side: with Telnyx you validate against live keys, so cap test volume and cost.
  • No free developer credit: there is no trial balance to burn through first.
  • Sender field: Telnyx’s from needs a real number or registered sender ID, not the free-text name Rule accepted.
  • Per-part billing: Telnyx bills per message part, so long or Unicode SMS that split into multiple parts multiply the per-send cost.
  • Data region: Telnyx is US-headquartered and offers both US and EU; if you must stay EU-only, select the EU region explicitly rather than relying on defaults.

For a full side-by-side, see the Rule vs. Telnyx comparison.