messaging.dev
→Migration guide

How to migrate from SMS.to to Vonage

A developer-focused guide to moving your messaging integration from SMS.to to Vonage: channel and compliance differences, request-format mapping, and a step-by-step migration checklist.

SMS.to is an omnichannel business messaging platform and API from Cyprus-based Intergo Telecom, covering SMS, Viber, WhatsApp, RCS and Telegram. Vonage is a communications-API provider (part of Ericsson) for SMS, voice, video and messaging. On the messaging.dev Score, SMS.to rates 49/100 and Vonage 89/100; this guide covers what actually changes for your integration when you move.

What changes when you move

Channels. You keep SMS, RCS, WhatsApp and Viber. You gain MMS, Facebook Messenger and Voice, which SMS.to does not offer. You lose Telegram, which SMS.to supports and Vonage does not. Neither provider offers Apple Messages for Business or email.

Compliance. Both are GDPR-compliant and ISO 27001 certified. Vonage additionally lists SOC 2 and HIPAA; SMS.to does not.

Data residency. Both run EU and US servers and let you choose a data-processing region. Vonage also lists APAC and Australia regions.

Pricing and credit. Both bill prepaid, pay-as-you-go, with volume discounts and free trial credit (SMS.to: trial credits on sign-up; Vonage: €2). Advertised rates differ: SMS.to from $0.023 per SMS versus Vonage at approximately $0.0072 per US SMS segment (plus carrier fees), though per-country rates vary either way.

Tooling. SMS.to ships a single PHP SDK, rates “med” on docs, and has no sandbox. Vonage ships seven SDKs (Node.js, Python, PHP, Java, C#, Ruby, Kotlin), rates “high” on docs, and offers a sandbox test environment. One trade-off: SMS.to exposes both REST and SMPP, while Vonage is REST-only.

For a full field-by-field view, see the head-to-head comparison.

How the request format differs

SMS.to quickstart:

curl -X POST https://api.sms.to/sms/send \
  -H "Authorization: Bearer <api_key>" \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello from SMS.to", "to": "+35794000001", "sender_id": "SMSto"}'

Vonage quickstart:

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'

Endpoint. SMS.to posts to a single https://api.sms.to/sms/send. Vonage’s legacy SMS API posts to https://rest.nexmo.com/sms/json; alternatively you can target the newer Messages API at https://api.nexmo.com/v1/messages for multichannel sends.

Authentication. SMS.to authenticates with an API key as a Bearer token in the Authorization header. Vonage’s SMS API instead takes an API key plus API secret passed as body parameters, while its Messages API uses JWT auth. You are moving credentials out of the header and into the request body (or switching to JWT).

Payload mapping. Recipient to maps to to (note Vonage’s example uses plain digits with no leading +); sender sender_id maps to from; message body message maps to text. SMS.to sends JSON (Content-Type: application/json); the Vonage SMS example is form-encoded.

Migration checklist

  1. Create a Vonage account and generate an API Key + API Secret (or a JWT/application for the Messages API). See how to start with Vonage.
  2. Map your request fields: message → text, sender_id → from, keep to (adjust number formatting to plain digits).
  3. Switch auth: replace the Bearer header with api_key/api_secret body params, or adopt JWT for the Messages API.
  4. Re-point your sending code to the new endpoint, and swap the PHP SDK for a Vonage SDK if you use one.
  5. Re-test in Vonage’s sandbox before sending live traffic (Vonage provides one; SMS.to did not).
  6. Update your webhooks and delivery-status callbacks to Vonage’s payload format and URLs.
  7. Run both providers in parallel, compare delivery, then cut over and decommission the SMS.to integration.

Watch out for

  • Telegram goes away. Vonage does not support it, so re-route those users to another channel before cutover.
  • No SMPP. Vonage is REST-only; any SMPP binding to SMS.to must be rebuilt on REST.
  • Two APIs to choose between. Legacy SMS API (key + secret) versus Messages API (JWT). Pick the Messages API if you want the extra channels under one integration.
  • Secret in the body. On the legacy SMS API your api_secret travels in the request body rather than a header, so keep those calls server-side.

There is no downgrade in certifications, data residency, docs quality, or free credit: Vonage matches or exceeds SMS.to on each of those dimensions.

Start with Vonage →Full comparisonAll guides