Migration guide

How to migrate from SmsManager to Infobip

A developer-focused guide to migrating from SmsManager to Infobip, covering channel and compliance differences, request-format changes, and a step-by-step cutover checklist.

SmsManager is a Prague-based Czech bulk-messaging platform for sending SMS, WhatsApp, Viber and RCS from a single JSON API. Infobip is a global omnichannel communications platform that adds voice, email and several chat apps on top of the same channels. On the messaging.dev Score, SmsManager rates 51/100 and Infobip 96/100. This guide covers what changes when you move your sending code from one to the other, with every claim drawn from the two dataset entries.

What changes at a glance

Channels you gain: MMS, Facebook Messenger, Telegram, voice and email. Channels you lose: none — every channel SmsManager offers (SMS, RCS, WhatsApp, Viber, Apple Messages for Business) is also on Infobip.

Compliance: both are GDPR-aligned. Moving to Infobip adds ISO 27001, SOC 2 and HIPAA, which SmsManager does not list.

Data residency: SmsManager runs EU servers only, with no US option and no region choice. Infobip offers both EU and US servers, an explicit data-residency choice, and additional regions (APAC, Latin America, Middle East, Africa).

Pricing: this is the main trade-off. SmsManager uses transparent prepaid pay-as-you-go credit with a published starting price (€0.0356 per SMS to the Czech Republic). Infobip is primarily quote/contract-based (contact sales), with some pay-as-you-go options and no publicly listed price.

SDKs and protocols: SmsManager ships JavaScript/TypeScript and PHP SDKs over REST. Infobip ships Java, C#, Python, PHP, Go and Node.js, and supports REST, SMPP and SMTP. PHP is the one SDK common to both.

Unchanged: both offer self-onboarding, free developer credit, a sandbox, high-quality docs and direct operator connections. Country coverage is comparable (175 vs 190). See the full head-to-head comparison for the rest.

How the request format differs

SmsManager quickstart:

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

Infobip quickstart:

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 / base URL. SmsManager posts to a single fixed host, https://api.smsmngr.com/v2/message. Infobip posts to /sms/2/text/advanced under an account-specific base URL, https://{base_url}.api.infobip.com — use the personalized subdomain from your dashboard, not a shared host.
  • Authentication. SmsManager passes the key in an x-api-key header. Infobip uses Authorization: App {api_key}. Same idea, different header name and format.
  • Payload mapping. The message body moves from body to text. The recipient moves from a top-level to array of { "phone_number": ... } objects to messages[].destinations[].to. SmsManager’s example omits a sender; Infobip carries a from field (e.g. "InfoSMS"), so add one. Infobip also wraps each send in a top-level messages array, so a single message becomes one element of that array.

Migration checklist

  1. Create an Infobip account (self-onboarding, free trial credit) and generate an API key; note your account-specific base URL. See how to start with Infobip.
  2. Map the request fields: bodytext, to/phone_numberdestinations/to, and add a from sender.
  3. Swap the auth header from x-api-key: KEY to Authorization: App KEY.
  4. Re-point sending code to https://{base_url}.api.infobip.com/sms/2/text/advanced, or adopt an official SDK (Node.js, Python, etc.).
  5. Re-test in Infobip’s sandbox before sending live traffic.
  6. Update delivery-report webhooks and callback URLs to Infobip’s format.
  7. Run both providers in parallel and compare delivery.
  8. Cut over, then decommission the SmsManager integration.

Watch out for

  • Pricing transparency. You move from published prepaid pay-as-you-go rates to a primarily quote/contract-based model with no public price — budget a sales/quote step before committing.
  • Account-specific base URL. Don’t hardcode a shared host; each account has its own {base_url} subdomain.
  • Auth header format. The scheme differs (x-api-key vs Authorization: App), an easy thing to miss when re-pointing code.
  • No downgrades in coverage. No channel or certification is lost in this move; verify parity on the comparison page before you cut over.