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/advancedunder 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-keyheader. Infobip usesAuthorization: App {api_key}. Same idea, different header name and format. - Payload mapping. The message body moves from
bodytotext. The recipient moves from a top-leveltoarray of{ "phone_number": ... }objects tomessages[].destinations[].to. SmsManager’s example omits a sender; Infobip carries afromfield (e.g."InfoSMS"), so add one. Infobip also wraps each send in a top-levelmessagesarray, so a single message becomes one element of that array.
Migration checklist
- 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.
- Map the request fields:
body→text,to/phone_number→destinations/to, and add afromsender. - Swap the auth header from
x-api-key: KEYtoAuthorization: App KEY. - Re-point sending code to
https://{base_url}.api.infobip.com/sms/2/text/advanced, or adopt an official SDK (Node.js, Python, etc.). - Re-test in Infobip’s sandbox before sending live traffic.
- Update delivery-report webhooks and callback URLs to Infobip’s format.
- Run both providers in parallel and compare delivery.
- 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-keyvsAuthorization: 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.