How to migrate from LINK Mobility to Twilio

LINK Mobility is a European communications-platform-as-a-service (CPaaS) provider based in Oslo that sends SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email over REST, SMPP, and SOAP APIs. Twilio is a San Francisco-based customer-engagement platform exposing communications APIs for SMS, voice, email, and more. On the messaging.dev Score, LINK Mobility rates 36/100 and Twilio rates 88/100; this guide walks through what actually changes when you move a sending integration from one to the other.

What you gain and what you lose

Channels. Both providers support SMS, MMS, RCS, WhatsApp, voice, and email, so that traffic carries over unchanged. Moving to Twilio, you lose three channels LINK Mobility supports: Viber, Facebook Messenger, and Telegram. Neither provider offers Apple Messages for Business, and Twilio adds no messaging channel that LINK Mobility lacks — so this move trades channel breadth for tooling and reach.

Protocols. LINK Mobility exposes REST, SMPP, and SOAP; Twilio offers REST and SMTP only. Any traffic running over an SMPP bind or SOAP has no Twilio equivalent and must be rebuilt on REST.

Compliance. Both are GDPR and ISO 27001 aligned. Twilio additionally carries SOC 2 and HIPAA, so you gain certifications without losing any.

Data residency. LINK Mobility runs on EU servers only, with no region choice. Twilio offers EU and US servers (plus Australia) and lets you choose data residency — a superset of LINK’s footprint.

Pricing, onboarding, and tooling. LINK Mobility uses volume-based enterprise pricing negotiated through sales, with no published rate, no self-onboarding, and no free credit. Twilio is self-service with published pay-as-you-go pricing (from $0.0079 per US SMS segment, plus carrier fees), a $15 trial credit, and a sandbox. Twilio’s docs rate “high” versus LINK’s “med”, and Twilio ships official SDKs for Node.js, Python, PHP, Java, C#, Ruby, and Go, where LINK lists none. See the full side-by-side comparison.

How the request format differs

LINK Mobility quickstart:

curl -X POST https://n-eu.linkmobility.io/sms/send \
  -u "USERNAME:PASSWORD" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "LINK",
    "destination": "+4799999999",
    "userData": "Hello world",
    "platformId": "0",
    "platformPartnerId": "0",
    "useDeliveryReport": false
  }'

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

Both providers authenticate with HTTP Basic, but the credentials differ. LINK Mobility uses a username and password issued by LINK Mobility Support, with each account assigned a regional base URL (n-eu/c-eu/s-eu.linkmobility.io) and requests POSTed to /sms/send. Twilio uses your Account SID as the username and your Auth Token as the password, and embeds that Account SID in the endpoint path.

Three structural changes stand out:

• Endpoint: /sms/send on a regional host becomes /2010-04-01/Accounts/{AccountSid}/Messages.json on api.twilio.com.
• Encoding: LINK sends a JSON body (Content-Type: application/json); Twilio expects form-urlencoded parameters.
• Field mapping: recipient destination → To, sender source → From, message body userData → Body. LINK’s platformId, platformPartnerId, and useDeliveryReport have no Twilio counterpart; on Twilio, delivery receipts are configured with a StatusCallback URL rather than a request flag.

Migration checklist

1. Create a Twilio account (self-service) and copy your Account SID and Auth Token; the $15 trial credit lets you test before committing. For a full walkthrough, see how to start with Twilio.
2. Map the request fields: destination → To, source → From, userData → Body, and drop platformId/platformPartnerId/useDeliveryReport.
3. Switch the payload from JSON to form-urlencoded and point requests at the new Account SID endpoint.
4. Re-point your sending code, optionally adopting an official Twilio SDK.
5. Re-test against Twilio’s sandbox before sending live traffic.
6. Update webhooks and delivery callbacks: replace LINK’s useDeliveryReport flag with a Twilio StatusCallback URL.
7. Run both integrations in parallel and compare delivery.
8. Cut over once you are confident.

Watch out for

• Channels dropped. Viber, Facebook Messenger, and Telegram are not available on Twilio; if you send on any of them, you will need another route.
• Protocols dropped. No SMPP or SOAP — existing binds and SOAP calls must be re-implemented over REST.
• Sender identity. LINK’s alphanumeric source (e.g. LINK) maps to a From that must be a Twilio-provisioned number or an approved sender.
• Carrier fees. Twilio’s published $0.0079 per US SMS segment is before carrier surcharges, so model total cost accordingly.