Migration guide

How to migrate from Attentive to Telnyx

A developer-focused guide to moving from Attentive's event-triggered marketing APIs to Telnyx's direct-send CPaaS messaging API, covering channels, compliance, and request-format changes.

Attentive is an AI-powered SMS, MMS, RCS, email, and push marketing platform for consumer brands: its REST and GraphQL APIs manage subscribers and trigger event-based journeys rather than sending messages directly. Telnyx is a licensed telecom carrier running a CPaaS platform with direct-send APIs for SMS, MMS, RCS, WhatsApp, voice, and email over its own global IP network. On the messaging.dev Score, Attentive rates 40/100 and Telnyx 78/100 — this guide covers the concrete API and capability changes involved in moving between them.

What you gain and what you lose

  • Channels: Both cover SMS, MMS, RCS, and email. Telnyx adds WhatsApp and voice; no channel is lost in the move. Neither supports Viber, Telegram, Facebook Messenger, or Apple Messages for Business.
  • Sending model: The largest change. Attentive has no direct send endpoint — you post events that fire pre-built journeys. Telnyx exposes a direct POST /messages endpoint where you compose and send each message yourself.
  • Compliance: Both hold GDPR and SOC 2. Telnyx adds ISO 27001 and HIPAA, so no certification is lost.
  • Data residency: Attentive processes on US servers only, with no region choice. Telnyx offers US and EU servers plus Asia-Pacific and South America, with data-residency choice.
  • Pricing: Attentive is custom-quoted with no published rates and no self-serve signup. Telnyx is self-serve, pay-as-you-go from $0.004 per outbound SMS message part (US, plus carrier fees).
  • SDKs: Attentive ships mobile SDKs (iOS/Swift, Android/Kotlin, React Native). Telnyx ships server-side SDKs (Node.js, Python, Ruby, Go, Java, .NET, PHP).
  • API surface and docs: Attentive offers REST + GraphQL, a sandbox, and mid-tier docs. Telnyx offers REST + SMPP and high-quality docs, but no sandbox. Neither includes a free developer credit.

A full side-by-side is on the Attentive vs Telnyx comparison.

How the request format differs

Attentive quickstart:

curl -X POST 'https://api.attentivemobile.com/v1/events/custom' \
  -H 'Authorization: Bearer <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "Order Shipped",
    "user": { "phone": "+13115552368" },
    "properties": { "Order Id": "54321" }
  }'

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://api.attentivemobile.com/v1/events/custom to https://api.telnyx.com/v2/messages.

Authentication: both use a Bearer API key in the Authorization header, so the header shape is unchanged. Attentive additionally supports OAuth 2.0 (authorization code) with scopes such as events:write for public apps; Telnyx uses the Bearer key only.

Payload mapping:

  • Recipient: Attentive nests it as user.phone; Telnyx uses a top-level to string.
  • Sender: Attentive has no sender field — the journey owns the number. Telnyx requires an explicit from number.
  • Message body: Attentive sends no message text at all — you post an event type plus properties, and a journey template supplies the copy. Telnyx carries the literal message in text.

In short: with Attentive you emit an event and let a journey decide what and whether to send; with Telnyx you assemble the full message and send it directly.

Migration checklist

  1. Create a Telnyx account and generate an API key (self-serve — see how to start with Telnyx). Provision a sending number or messaging profile for your from.
  2. Map your request fields: user.phoneto, add an explicit from, and move message copy out of Attentive journey templates into the text field or your own templating.
  3. Re-point your sending code from the events endpoint to https://api.telnyx.com/v2/messages, keeping the Bearer header.
  4. Replace event-trigger logic: wherever you posted an event to fire a journey, call the send endpoint directly and own the timing and orchestration yourself.
  5. Re-test. Telnyx has no sandbox, so validate against a small set of live test numbers at low volume rather than an isolated environment.
  6. Update webhooks and delivery callbacks to consume Telnyx delivery events instead of Attentive’s.
  7. Run both in parallel — keep Attentive live while you shadow-send or split a fraction of traffic through Telnyx and reconcile delivery.
  8. Cut over once delivery, opt-out handling, and reporting match.

Watch out for

  • No sandbox. Attentive provides a test environment; Telnyx does not. Plan to test against live numbers with minimal volume.
  • You own composition and orchestration. Attentive’s journeys handled send logic, throttling, and copy; with a direct-send API that responsibility moves into your code.
  • No GraphQL. If you relied on Attentive’s GraphQL API, Telnyx offers REST and SMPP only.
  • SDK platform shift. Telnyx has no mobile SDKs; client-side integrations built on Attentive’s Swift, Kotlin, or React Native SDKs need a server-side rewrite.
  • No free developer credit. Neither provider includes one, so budget for paid test traffic from day one.