How to migrate from LINK Mobility to Infobip

LINK Mobility is a European communications-platform-as-a-service (CPaaS) provider offering SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email through REST, SMPP, and SOAP APIs. Infobip is a global omnichannel communications platform covering the same channels plus Apple Messages for Business. On the messaging.dev Score, LINK Mobility rates 36/100 and Infobip 96/100 — this guide covers what actually changes at the API level when you migrate.

Channels you gain and lose

Both providers support SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email, so you lose no channel by moving. Infobip adds one channel LINK Mobility lacks: Apple Messages for Business. If your roadmap needs it, that is a net gain; otherwise your channel mix carries over unchanged.

Compliance, residency, and developer experience

Both hold GDPR and ISO 27001. Infobip additionally carries SOC 2 and HIPAA, which LINK Mobility does not — relevant if you handle US healthcare data or need a SOC 2 attestation.

On data residency, LINK Mobility runs EU servers only, with no US option and no region choice. Infobip offers both EU and US servers plus explicit data-residency choice and additional regions (APAC, Latin America, Middle East, Africa).

Developer experience differs more sharply. LINK Mobility publishes no SDKs, has no sandbox, medium-rated docs, no free developer credit, and requires a sales activation call. Infobip is self-onboarding, ships SDKs for Java, C#, Python, PHP, Go, and Node.js, provides a sandbox, high-rated docs, and free trial credit. Both use quote/contract-based pricing with no published per-message rate, so pricing is roughly a wash — Infobip lists some pay-as-you-go options.

One transport note: LINK Mobility exposes REST, SMPP, and SOAP; Infobip exposes REST, SMPP, and SMTP. They share REST and SMPP, but SOAP is not available on Infobip.

How the request format differs

LINK Mobility:

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

Infobip:

curl -X POST 'https://xxxxxx.api.infobip.com/sms/2/text/advanced' \
  -H 'Authorization: App YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"messages":[{"from":"InfoSMS","destinations":[{"to":"15551234567"}],"text":"Hello from Infobip"}]}'

Three things change:

• Endpoint. You move from https://n-eu.linkmobility.io/sms/send (a fixed regional host) to https://{base_url}.api.infobip.com/sms/2/text/advanced, where {base_url} is the account-specific host from your Infobip dashboard.
• Authentication. LINK Mobility uses HTTP Basic auth (-u USERNAME:PASSWORD, sent as an Authorization: Basic header). Infobip uses an API key in an Authorization: App YOUR_API_KEY header. (LINK’s newer MyLINK/XMS API also supports OAuth2 Bearer tokens.)
• Payload shape. LINK Mobility sends a flat, single-message object. Infobip wraps everything in a messages array. Field mapping: source → from, destination (a top-level string) → destinations: [{ "to": ... }] (an array of objects), and userData → text. LINK’s platformId, platformPartnerId, and useDeliveryReport have no direct Infobip equivalent.

Migration checklist

1. Create an Infobip account and generate an API key from the dashboard (self-onboarding, no sales call required). See how to start with Infobip.
2. Note your account-specific {base_url} host.
3. Map the request fields: source → from, destination → destinations[].to, userData → text; wrap it all in the messages array.
4. Swap HTTP Basic auth for the Authorization: App API-key header.
5. Re-point your sending code to the new endpoint, or adopt an official Infobip SDK.
6. Re-test in Infobip’s sandbox before sending live traffic.
7. Update delivery-report/webhook callbacks to Infobip’s format (LINK’s useDeliveryReport flag no longer applies).
8. Run both providers in parallel, verify delivery, then cut over.

Watch out for

• No SOAP. If any current integration uses LINK Mobility’s SOAP API, Infobip offers no SOAP equivalent — you will need REST or SMPP.
• Payload restructuring. The flat single-message object becomes a nested messages/destinations array; this is not a field rename but a structural change your code must handle.
• Sender IDs and numbers re-provision. Sender IDs, numbers, and channel registrations (WhatsApp, RCS) must be set up again on Infobip; they do not transfer.
• Pricing still needs a quote. Neither provider publishes per-message rates, so confirm Infobip pricing for your volumes before cutover.

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