How to migrate from SmsManager to Vonage

SmsManager is a Czech bulk-messaging platform for sending SMS, WhatsApp, Viber and RCS from a single JSON API, while Vonage is a broader communications-API provider (part of Ericsson) covering SMS, voice, video and messaging. On the messaging.dev Score the two sit far apart — SmsManager rates 51/100 and Vonage 89/100 — largely because of Vonage’s wider channel, SDK and compliance coverage. This guide maps the concrete differences and shows how to re-point your sending code.

What you gain and lose

Channels. Both providers cover SMS, RCS, WhatsApp and Viber, so those integrations carry over. Moving to Vonage adds MMS, Facebook Messenger and voice. The one channel you lose is Apple Messages for Business, which SmsManager supports and Vonage does not. Neither offers Telegram or email.

Compliance. Both are GDPR-aligned. Vonage additionally holds ISO 27001, SOC 2 and HIPAA, which SmsManager’s dataset entry does not list — relevant if you need those attestations.

Data residency. SmsManager runs EU servers only, with no region choice. Vonage offers both EU and US servers, lets you choose a data-residency region, and adds APAC and Australia.

Pricing & credit. SmsManager uses prepaid, non-expiring credit charged per message; Vonage is pay-as-you-go per message/minute with volume discounts. Both give free trial credit to start (Vonage specifies €2).

SDKs, sandbox, docs. SmsManager ships JavaScript/TypeScript and PHP SDKs; Vonage adds Node.js, Python, Java, C#, Ruby and Kotlin. Both are REST, both offer a sandbox, and both rate high on docs quality. See how to start with Vonage for the target’s quickstart, or the full SmsManager vs Vonage comparison.

How the request format differs

SmsManager:

curl -X POST https://api.smsmngr.com/v2/message \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"body": "Hello from SmsManager!", "to": [{"phone_number": "420777123456"}]}'

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'

Three things change:

• Endpoint. You move from https://api.smsmngr.com/v2/message to Vonage’s https://rest.nexmo.com/sms/json (legacy SMS API) or https://api.nexmo.com/v1/messages (Messages API).
• Auth. SmsManager authenticates with a single x-api-key header. The Vonage SMS API takes an api_key plus api_secret (sent as request parameters); the Messages API uses JWT auth instead.
• Payload. SmsManager sends a JSON body; the Vonage SMS API is form-encoded. The message text moves from body to text. The recipient collapses from an array of objects ("to": [{"phone_number": "…"}]) to a single to string. Vonage also requires an explicit from sender, which the SmsManager call does not include.

Migration checklist

1. Create a Vonage account and generate your API key and secret (or an application plus JWT for the Messages API).
2. Map each request field: body → text, the to array → a single to string, and add a from sender.
3. Re-point your sending code to the new endpoint and switch auth from the x-api-key header to api_key/api_secret (or JWT).
4. Re-test against Vonage’s sandbox before sending live traffic.
5. Update delivery/webhook callbacks to consume Vonage’s status payloads.
6. Run both integrations in parallel and reconcile delivery results.
7. Cut over once Vonage matches your baseline, then retire the SmsManager path.

Watch out for

• Apple Messages for Business goes away. If any flow uses it, there is no equivalent on Vonage — plan a fallback channel.
• Secret travels in the request. The Vonage SMS API sends api_secret as a parameter rather than a header; keep it out of logs and prefer the JWT-based Messages API where you can.
• Form-encoded, not JSON. Any JSON-body assumptions carried over from SmsManager need rewriting for the legacy SMS API.
• Sender is now required. Vonage expects an explicit from; the SmsManager call did not.