How to migrate from LINK Mobility to Vonage
A developer-focused guide to moving SMS and messaging traffic from LINK Mobility to Vonage, covering channel and compliance differences, request-format changes, and a step-by-step migration checklist.
LINK Mobility is a European communications-platform-as-a-service (CPaaS) provider offering SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email over REST, SMPP, and SOAP APIs. Vonage is a communications-APIs platform (part of Ericsson) covering SMS, voice, video, and messaging over a REST API. On the messaging.dev Score, LINK Mobility rates 36/100 and Vonage 89/100; this guide covers what actually changes when you move.
Channels you keep, gain, and lose
Both providers cover the same core set: SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, and voice. Neither supports Apple Messages for Business. Moving to Vonage means you lose two channels that LINK Mobility offers: Telegram and email. There are no new channels to gain. If your current stack sends on Telegram or email, plan a separate provider for those before you cut over.
Compliance, residency, and pricing
Both hold GDPR and ISO 27001. Vonage additionally holds SOC 2 and HIPAA. On data residency, LINK Mobility runs EU servers only with no region choice, while Vonage offers EU and US servers plus APAC and Australia, with an explicit data-residency choice. The pricing model also differs in transparency: LINK Mobility uses volume-based enterprise pricing negotiated through sales, with per-message rates not published; Vonage publishes pay-as-you-go rates (approximately $0.0072 per US SMS segment, plus carrier fees) with volume discounts. Vonage adds a €2 free trial credit and self-service onboarding; LINK Mobility offers neither and may require a short activation call.
Tooling and docs
LINK Mobility ships no official SDKs and has no sandbox, and its docs are rated medium. Vonage ships SDKs for Node.js, Python, PHP, Java, C#, Ruby, and Kotlin, provides a sandbox test environment, and its docs are rated high. One trade-off runs the other way: LINK Mobility exposes REST, SMPP, and SOAP, whereas Vonage is REST-only, so any SMPP or SOAP integration must be rebuilt on REST.
How the request format differs
Source (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
}'
Target (Vonage):
curl -X POST 'https://rest.nexmo.com/sms/json' \
-d 'api_key=YOUR_API_KEY' \
-d 'api_secret=YOUR_API_SECRET' \
-d 'from=Vonage' \
-d 'to=15551234567' \
-d 'text=Hello from Vonage'
The base URL changes from LINK Mobility’s regional host https://n-eu.linkmobility.io/sms/send to https://rest.nexmo.com/sms/json (legacy SMS API) or https://api.nexmo.com/v1/messages (Messages API). Authentication changes too: LINK Mobility uses HTTP Basic Authentication (the -u username:password Authorization header); Vonage uses an API Key plus API Secret passed as request parameters on the SMS API, or JWT auth on the Messages API. The payload structure shifts from a JSON body to form-encoded parameters, and the field names map as follows: source becomes from, destination becomes to, and userData becomes text. LINK-specific fields such as platformId, platformPartnerId, and useDeliveryReport have no direct Vonage equivalent.
Migration checklist
- Create a Vonage account and generate your API Key and API Secret, or set up a JWT application for the Messages API. See how to start with Vonage for the walkthrough.
- Map the request fields: endpoint, auth mechanism, and payload (
sourcetofrom,destinationtoto,userDatatotext). - Re-point your sending code to the new base URL and switch from a JSON body to form-encoded parameters (or adopt the Messages API JSON schema).
- Re-test in Vonage’s sandbox, which it provides, before sending any live traffic.
- Update delivery-report webhooks and callbacks; LINK’s
useDeliveryReportflag has no direct equivalent, so configure DLR callbacks on the Vonage side. - Run both providers in parallel, comparing delivery and error rates on real numbers.
- Cut over and decommission the LINK Mobility path.
Watch out for
- You lose Telegram and email as channels; if you use them today, keep or add a provider that covers them.
- You lose SMPP and SOAP access; Vonage is REST-only, so protocol-level integrations need rework.
- No certification regresses in this move: Vonage adds SOC 2 and HIPAA on top of the shared GDPR and ISO 27001, so compliance coverage widens rather than narrows.
For a full side-by-side, see the LINK Mobility vs Vonage comparison.