Migration guide

How to migrate from Attentive to Sinch

A developer-focused guide to moving from Attentive's event-triggered marketing APIs to Sinch's direct-send messaging APIs, with field mapping and a migration checklist.

Attentive is an AI-powered SMS, MMS, RCS, and email marketing platform for consumer brands, built around REST and GraphQL APIs for subscriber management and event-triggered messaging rather than direct message sending. Sinch is a cloud communications platform offering messaging, voice, and email APIs with direct message sending. On the independent messaging.dev Score, Attentive rates 40/100 and Sinch 92/100 — a gap that mostly reflects channel breadth, compliance coverage, and data-residency options, detailed below.

What you gain and what you lose

Channels. Both support SMS, MMS, RCS, and email. Moving to Sinch adds WhatsApp, Viber, Facebook Messenger, Telegram, Apple Messages for Business, and Voice. You lose no channels — every channel Attentive exposes is also on Sinch.

Compliance. Both hold GDPR and SOC 2. Sinch additionally lists ISO 27001 and HIPAA, neither of which Attentive lists.

Data residency. Attentive runs on US servers only, with no EU option and no region choice. Sinch offers both US and EU servers, lets you choose a residency region, and additionally covers APAC, Australia, and Brazil.

Pricing and onboarding. Attentive is custom-quoted, usage-based, with no self-serve signup and no published per-message rates. Sinch is pay-as-you-go (approx. $0.0075 per US SMS segment, plus carrier fees), supports self-onboarding, and includes free developer credit — which Attentive does not.

SDKs and docs. Attentive ships client-side SDKs (iOS/Swift, Android/Kotlin, React Native); Sinch ships server-side SDKs (Java, Python, C#, Node.js, PHP). Both provide a sandbox. Attentive’s docs are rated medium, Sinch’s high. Country coverage grows from 20 to 150, and Sinch adds direct operator connections and a 99.95% uptime SLA (Attentive publishes none).

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

Sinch quickstart:

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

The base URL changes from https://api.attentivemobile.com/v1 to https://us.sms.api.sinch.com/xms/v1/{service_plan_id}/batches. Note that the Sinch path embeds a service_plan_id and is region-pinned (the us. host).

Auth is Bearer in both, but the concepts differ. Attentive uses a Bearer API key for private apps (or OAuth 2.0 with scopes such as events:write for public apps); Sinch uses a Bearer API token tied to your service plan.

The payload is where the two models diverge most. Attentive has no direct send-SMS endpoint — you POST an event (type) carrying a user.phone recipient and properties, and a journey decides what to send. Sinch sends message content directly: to is an array of recipients, from is your sender, and body is the literal message text. Mapping: user.phoneto[]; there is no Attentive equivalent for from (the sending number lives in the journey); and there is no body in Attentive at all — the message text lives in the journey, so you must supply it explicitly in Sinch’s body.

Migration checklist

  1. Create a Sinch account (self-serve), then generate an API token and note your service_plan_id.
  2. Pick your region/base URL and confirm the data-residency region you need (US or EU).
  3. Map request fields: user.phoneto[], add an explicit from, and move the message text out of the Attentive journey into body.
  4. Re-point your sending code from the events endpoint to the Sinch batches endpoint, and swap the Authorization header token.
  5. Re-test against Sinch’s sandbox before sending live traffic (Sinch provides one).
  6. Update delivery callbacks/webhooks to consume Sinch delivery reports instead of Attentive event/journey status.
  7. Run both in parallel on a subset of traffic, compare delivery, then cut over.

Watch out for

  • No GraphQL on Sinch. Attentive exposes REST and GraphQL; Sinch is REST (plus SMTP/SMPP). GraphQL callers will rewrite to REST.
  • No client-side SDKs. Attentive’s iOS/Android/React Native SDKs have no Sinch equivalent — Sinch’s SDKs are server-side only.
  • No built-in journey orchestration. Sinch sends message content directly, so the subscriber-management and event-triggered journey logic Attentive handled must be built or sourced elsewhere.

For a deeper setup walkthrough, see how to start with Sinch, or view the full Attentive vs Sinch comparison.