Migration guide

How to migrate from Attentive to Twilio

A developer-focused guide to moving from Attentive's event-triggered messaging to Twilio's direct-send communications API, covering channels, compliance, request-format changes, and a step-by-step migration checklist.

Attentive is an AI-powered SMS, MMS, RCS, email, and push marketing platform for consumer brands, exposing REST and GraphQL APIs for subscriber management and event-triggered messaging rather than direct sends. Twilio is a customer-engagement platform with communications APIs for SMS, voice, email, and more. On the messaging.dev Score, Attentive rates 40/100 and Twilio 88/100 — this guide covers what actually changes at the API level when you move between them.

What you gain and what you lose

Channels. Both platforms cover SMS, MMS, RCS, and email. Moving to Twilio adds WhatsApp and voice; no channel that Attentive supports is dropped. Neither supports Viber, Facebook Messenger, Telegram, or Apple Messages for Business.

Compliance. Both hold GDPR and SOC 2. Twilio additionally carries ISO 27001 and HIPAA, which Attentive does not.

Data residency. Attentive runs on US servers only, with no region choice. Twilio offers US and EU servers (plus Australia) and a data-residency choice.

Pricing and onboarding. Attentive is a custom-quoted, usage-based subscription with no self-serve signup, no published per-message rates, and no free developer credit. Twilio is self-serve and pay-as-you-go — $0.0079 per US SMS segment (plus carrier fees) — and includes a $15 trial credit.

SDKs. Attentive ships mobile SDKs (iOS/Swift, Android/Kotlin, React Native); Twilio ships server-side SDKs (Node.js, Python, PHP, Java, C#, Ruby, Go). Country coverage rises from 20 to 180, and documentation quality goes from medium to high. Both offer a sandbox. One difference to note: Attentive exposes REST and GraphQL, while Twilio is REST and SMTP only (no GraphQL). For the full side-by-side, see Attentive vs Twilio.

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

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

The biggest shift is architectural. Attentive has no direct send-SMS endpoint: you POST a custom event to /events/custom, and Attentive’s journeys decide what (if anything) to send. Twilio’s endpoint sends a literal message directly.

  • Endpoint / base URL: https://api.attentivemobile.com/v1/events/custom becomes https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json.
  • Authentication: Attentive uses a Bearer API key in the Authorization header. Twilio uses HTTP Basic auth — Account SID as username, Auth Token as password (the -u flag).
  • Payload: Attentive sends a JSON body; Twilio sends form-encoded fields. The recipient moves from the nested user.phone to a flat To field. Attentive carries no explicit sender, so Twilio’s required From number is new. And Attentive has no literal message text — the event type plus properties drive templated copy inside a journey — whereas Twilio expects the exact Body string.

Migration checklist

  1. Create a Twilio account (self-serve) and copy your Account SID and Auth Token from the dashboard; the $15 trial credit lets you test immediately. See how to start with Twilio.
  2. Provision a sender. Buy or verify a Twilio phone number (or Messaging Service) to use as From — Attentive did not require one.
  3. Map the request fields. Translate type + user.phone + properties into To / From / Body, and move the message copy that lived in Attentive journeys into your own Body strings.
  4. Re-point sending code. Change the base URL to Messages.json, swap the Bearer header for HTTP Basic (-u SID:token), and form-encode the payload.
  5. Swap SDKs. Replace Attentive’s mobile SDKs with a server-side Twilio SDK (e.g. Node.js or Python).
  6. Re-test in the sandbox. Twilio provides a test environment; validate there before sending live traffic.
  7. Update webhooks / delivery callbacks to point Twilio status callbacks at your own endpoints.
  8. Run both in parallel, confirm delivery, then cut over.

Watch out for

  • You lose the journey engine. With no event-triggered layer, you now own message composition, opt-out and compliance handling, and sender-number provisioning that Attentive managed for you.
  • From is mandatory. You must provision and pass a sender number on every request.
  • No mobile SDKs. Twilio’s official SDKs are server-side languages, so client-side integrations built on Attentive’s iOS/Android/React Native SDKs need rework.
  • No GraphQL. Twilio is REST and SMTP only.
  • Per-message billing. Costs scale per segment ($0.0079 per US SMS plus carrier fees) rather than as a negotiated subscription.