How to migrate from LINK Mobility to Sinch

LINK Mobility is a European communications-platform-as-a-service (CPaaS) provider based in Oslo, offering SMS, MMS, RCS, and chat-app channels through REST, SMPP, and SOAP APIs. Sinch is a Stockholm-based cloud communications platform covering the same messaging channels plus voice and email. On the messaging.dev Score, LINK Mobility rates 36/100 and Sinch 92/100 — a gap driven largely by self-service onboarding, published pricing, SDK coverage, and broader compliance. The concrete differences are below.

What changes when you move

Channels. Both providers support SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email, so you lose no channel by migrating. You gain one: Apple Messages for Business, which Sinch supports and LINK Mobility does not.

Compliance. Both hold GDPR and ISO 27001. Sinch additionally lists SOC 2 and HIPAA, so no certification is lost in the move.

Data residency. LINK Mobility runs EU servers only, with no region choice. Sinch offers both EU and US servers, an explicit data-residency choice, plus APAC, Australia, and Brazil regions.

Onboarding and pricing. LINK Mobility is not self-service (activation can require a call with their team) and neither publishes per-message rates nor offers free developer credit; its pricing is volume-based and negotiated through sales. Sinch supports self-onboarding, publishes pay-as-you-go pricing (about $0.0075 per US SMS segment, plus carrier fees, with volume and committed-use options), and includes free trial credit.

Tooling. LINK Mobility ships no official SDKs, has no sandbox, and its docs are rated medium quality. Sinch provides SDKs for Java, Python, C#, Node.js, and PHP, a sandbox test environment, and docs rated high. The how to start with Sinch guide walks through that onboarding path.

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

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

Three things change. Endpoint: LINK Mobility POSTs to a fixed regional path (https://n-eu.linkmobility.io/sms/send); Sinch POSTs to https://us.sms.api.sinch.com/xms/v1/{service_plan_id}/batches, embedding your service-plan ID in the URL. Authentication: LINK Mobility uses HTTP Basic (-u "USERNAME:PASSWORD"); Sinch uses a Bearer token (Authorization: Bearer YOUR_API_TOKEN). Payload mapping: the sender field source becomes from; the recipient destination (a single string) becomes to (a JSON array of strings); the message body userData becomes body. LINK’s platformId, platformPartnerId, and useDeliveryReport fields have no direct Sinch equivalent and are simply dropped.

Migration checklist

1. Create a Sinch account (self-service) and generate an API token; note your service-plan ID.
2. Map each request field: source→from, destination→to (wrap it in an array), userData→body.
3. Swap the endpoint to the Sinch batches URL and replace HTTP Basic auth with the Bearer token header.
4. Re-point your sending code, then re-test against Sinch’s sandbox before touching live traffic.
5. Update delivery-report handling: LINK’s useDeliveryReport flag is gone, so re-wire delivery callbacks/webhooks to Sinch’s status model.
6. Run both providers in parallel, comparing delivery receipts on a sample of traffic.
7. Cut over once the Sinch path matches, then retire the LINK Mobility credentials.

Watch out for

• Region defaults. The Sinch quickstart host is US-based (us.sms.api.sinch.com), whereas LINK Mobility processes EU-only. Sinch offers EU servers and data-residency choice, so select the correct region if EU processing is a requirement.
• No SOAP. LINK Mobility exposes REST, SMPP, and SOAP; Sinch exposes REST, SMTP, and SMPP. Any integration built on LINK’s SOAP interface must be rewritten.
• Recipient shape. to is an array on Sinch — a structural change that is easy to miss when porting single-recipient code.

For a full side-by-side, see the LINK Mobility vs Sinch comparison.