REST API or SMPP for SMS in Sri Lanka?

Short answer: use a REST (HTTP) SMS API if you send up to moderate volumes, want to be live quickly and prefer stateless requests your existing web stack already understands. Choose SMPP when you push sustained high volumes, need a persistent connection with high throughput and already have, or are willing to run, the tooling to manage binds, windows and delivery receipts. Both reach the same handsets; the difference is operational.

Updated 29 October 2026.

What a REST SMS API and SMPP actually are

A REST or HTTP SMS API is a web endpoint. Your system sends an HTTPS request with an API key, a sender ID, the recipient number and the message text, and gets back a response with a message ID. Each request stands on its own, so it works from any language, serverless function or plugin that can make an HTTP call. Bloomwire's SMS gateway and API is built on this model, and our WooCommerce SMS plugin is a ready-made example of it.

SMPP (Short Message Peer-to-Peer) is a messaging protocol rather than a web API. The SMPP Developers Forum describes it as an open, industry-standard protocol for moving short message data between a message centre (SMSC) and an application system, which the specification calls an ESME. The most widely deployed version is v3.4. Key points from the v3.4 specification:

Your application opens a TCP session and binds as a transmitter (send only), receiver (receive only) or transceiver (send and receive over a single connection).
Messages go out with submit_sm; the SMSC answers each one with a response carrying a message ID.
Delivery receipts come back to you as deliver_sm (or data_sm) operations, but only if you requested one in the registered_delivery field.
The session is kept alive and checked with enquire_link.
Requests can be sent asynchronously; the specification recommends no more than 10 outstanding messages at a time as a guideline, while the SMSC sets the real limit.
The short_message field carries up to 254 octets; longer content uses message_payload or is split into concatenated parts.

Bloomwire offers SMPP as well as REST. We don't publish connection details; ask us for them when you set up your account. Our SMPP integration guide walks through binding, submitting, handling responses and delivery receipts, and retry logic.

When each one fits

Factor	REST / HTTP API	SMPP
Volume and throughput	Comfortable for alerts, OTPs and campaigns sent in batches	Built for sustained, high-throughput traffic over one open connection
Connection	Stateless; one HTTPS request per send (or per batch)	Persistent TCP session with bind, keep-alive and reconnect handling
Delivery receipts	Status lookup or callback, depending on the API	`deliver_sm` on a receiver or transceiver bind
Tooling	Any HTTP client	An SMPP client library or messaging gateway
Ops effort	Low: handle timeouts and errors	Higher: monitor binds, windows, throttling and reconnects
Typical owner	Web, e-commerce and app teams	Teams already running messaging infrastructure

A practical rule: start with REST unless you can name a throughput or latency need that REST will not meet, or you already operate an SMPP client. You can also mix them: REST for application events, SMPP for a dedicated high-volume system.

Sender IDs, encoding and message length

In Sri Lanka, the sender ID matters as much as the protocol. As our 2026 sender ID guide explains, unregistered alphanumeric sender IDs risk being blocked on the largest networks (Dialog, Hutch and Etisalat, with a deadline reported for 29 July 2026), and Mobitel is reported to accept only OTP, OTT and transactional traffic from registered IDs. With Bloomwire, we register your sender ID and submit it for approval before you go live, whichever protocol you use.

Encoding decides how many parts you pay for:

A message using only the GSM character set fits 160 characters in one SMS.
Any Unicode content, including Sinhala and Tamil, cuts this to 70 characters, or 67 per part once the message is split.
One emoji or a stray character outside the GSM set (such as a curly quote pasted from a word processor) switches the whole message to Unicode. Normalise text before sending, and count parts in your code so cost and length stay predictable.

Delivery reports, retries and idempotency

An accepted request means the gateway has your message, not that the handset has it. Delivery reports close that gap, and Bloomwire provides them in real time. Build around them:

Store the message ID returned for every send, alongside your own reference (order number, user ID, OTP request ID).
Treat timeouts carefully. An HTTP POST is not idempotent: if the connection drops after the gateway accepted the message, resending creates a duplicate. Check status first, or use a client reference so you can tell whether the first attempt landed.
Retry with back-off only on clear transient errors (network failures, throttling), never on validation errors such as a bad number or unregistered sender ID.
On SMPP, correlate each deliver_sm receipt to the message ID from the original submit_sm response, and re-bind automatically if the session drops.
Act on failures. Flag numbers that keep failing so you stop paying to send to them.

OTP specifics

One-time codes are where delivery speed and correctness matter most. Bloomwire sends OTPs as transactional SMS with high delivery priority, and our Verify API handles one-time codes by SMS and by WhatsApp authentication templates through a simple REST API. Whichever route you build, follow the verifier rules in NIST SP 800-63B-4:

Codes should be single-use and expire quickly; NIST treats an out-of-band authentication as invalid unless it is completed within 10 minutes.
Rate-limit failed attempts, and do not reset the failed-attempt count when a new code is issued.
NIST classes authentication over the phone network (which includes SMS) as "restricted", so offer a second channel or method for higher-risk actions.
Keep the OTP message short and in GSM characters where you can, so it fits in one part.

A sample request

This is the transactional SMS example from the Unecast developer hub. Every SMS call uses a Bearer token in the Authorization header, and the send call takes channel, from, to, message and priority:

curl -X POST https://api.unecast.com/v2/send \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "sms",
    "from": "YOURBRAND",
    "to": "94771234567",
    "message": "Your OTP is 482913",
    "priority": "high"
  }'

Keep the message ID from the response, then read the delivery status with GET https://api.unecast.com/v2/status/{message_id} before deciding whether anything needs a retry. GET https://api.unecast.com/v2/account/balance returns your account balance. SMPP is available for high-volume systems.

Frequently asked questions

Is SMPP faster than a REST API?

SMPP keeps one connection open and lets you send asynchronously, so it suits sustained high throughput. For alerts, OTPs and typical campaigns, a REST API is usually quick enough and much simpler to run.

Can I use both REST and SMPP with Bloomwire?

Yes. Bloomwire offers both. You can start with REST and add SMPP later if a system needs sustained high volume.

Do I need a registered sender ID for API or SMPP traffic?

Yes. Unregistered alphanumeric sender IDs risk being blocked on the main Sri Lankan networks. Bloomwire registers your sender ID and submits it for approval during setup.

How many parts is a Sinhala or Tamil SMS?

Unicode messages fit 70 characters in one SMS and 67 per part when split. A 150-character Sinhala message is three parts.

Why do I get duplicate messages after a timeout?

The first request was probably accepted before the connection dropped, and your code resent it. Store message IDs and your own reference, and check status before retrying.

Sources

Business MessagingSMPP APISMSSMS GatewaySri LankaTransactional SMS

Bloomwire team

Notes on messaging, voice and AI from the team building Sri Lanka's communication platform.

More insights

Sending SMS from your system in Sri Lanka: REST API or SMPP?