SMPP vs HTTP: which connection fits

A persistent SMPP session against per-request HTTP calls: throughput, receipts, callbacks and the failure modes that decide the choice.

Unicom Americas – Mobile Business team

practitioner · 4 min read

SMPP holds a persistent session with a throughput window per bind; HTTP authenticates each request and receives events at a callback. Both carry the same messages and report the same delivery states. Choose by traffic shape and by the failures your team can operate.

Key facts

SMPP keeps one session open and carries a window of in-flight requests per bind.
HTTP starts a new authenticated request for each send and uses a callback for receipts.
Both models return the same delivery states; the transport changes how they arrive.
The failure modes differ: a full bind window on SMPP, a slow callback on HTTP.

On this page

The decision in one paragraph

Start with HTTP if the volume is light, the traffic is bursty and the team already runs web endpoints. Move to SMPP when the traffic is a steady stream, when per-request authentication and connection setup become a visible cost, or when receipts must arrive on the same transceiver session as the sends. Many platforms run both: SMPP for the send stream and HTTP for inbound callbacks.

The protocol is not the product. The route, the sender registration and the handset checks decide whether a message arrives. SMPP and HTTP are two ways to reach the same message center, and either can be run well or badly.

The right question is not which protocol is newer. It is which failure your team can see and fix at the rate the traffic produces. A silent bind at two in the morning and a failing callback at two in the morning are both operational problems. Choose the one your tooling can diagnose.

The same job, two shapes

Both columns carry the same messages. The rows are the parts that change when you switch transports.
Item	SMPP	HTTP
Session	Authenticated bind held open	Key sent with every request
Window	Fixed in-flight window per bind	Concurrency set by the client and the pool
Delivery receipt	deliver_sm PDU on a transceiver (or separate receiver) bind	Callback to your endpoint
Inbound message	deliver_sm on a receiver or transceiver bind	Callback to your endpoint
Retry	Client manages the window and backoff	Client retries the request; provider retries the callback

The table describes the transport, not a provider's implementation. Confirm the details in onboarding.

Throughput follows the shape

An SMPP bind is provisioned for a throughput rate and a window. Once the session is open, a submit costs a PDU and a response, with no new handshake. That makes SMPP efficient for a sustained stream and predictable for capacity planning: count the binds, read the allocation, and keep the in-flight requests under the window.

HTTP pays for authentication and connection setup on each request, though connection reuse reduces the cost. Capacity comes from concurrency, not from a bind window, so the client can burst quickly and then hit a rate limit or a queue. That flexibility suits campaigns and low-volume applications; it also makes the peak harder to reason about unless the client caps concurrency. A rate limit and a window are different controls: one caps requests per second, the other caps requests in flight. The per-request cost is visible at high volume, not at a few thousand messages a day.

SMS throughput & campaign planner

Change the rate and the window; the planner runs in the browser.

Turn a message volume and sending window into the throughput you need, or a throughput into campaign duration.

tps: 50
windowMin: 60

Open the tool

Receipts and inbound decide the integration

SMPP delivers receipts and inbound messages over the open session. The client must keep the session alive to receive them, match each receipt to the stored message ID, and answer with deliver_sm_resp. There is no callback endpoint to secure, but there is a session to monitor: a bind that is open but silent is a failure mode.

HTTP delivers receipts and inbound messages to a URL. The receiver verifies the signature, answers quickly and processes the event asynchronously. A slow callback is the common failure: the provider times out, retries, and the same event is processed twice. Idempotency keys and a fast acknowledgement are part of the integration, not an optimization.

Whichever path carries the receipt, keep the raw payload. The provider's interpretation can change, and a support case often turns on the original state or error code. Store it with the message ID, the route and the time.

Failure modes to design for

Each row is a failure that appears in production, not a theoretical edge case.
Failure	What it looks like	What to do
Full bind window	Timeouts and retries rise together; the queue grows	Stop retrying, let the window drain, add a bind
Silent session	The bind is open but no response arrives	Send enquire_link, time out the session, reconnect with backoff
Receipt mismatch	States attach to the wrong message	Match by message ID, not by arrival order
Slow callback	The provider retries; duplicates appear	Acknowledge fast, process asynchronously, use an idempotency key
Missing idempotency	A network retry creates two messages	Carry a client reference and de-duplicate on it
Encoding drift	A long message arrives in pieces or with wrong characters	Set GSM-7 or UCS-2 deliberately and test the segment count

The fixes are operational. No transport removes the need for them.

Choosing and integrating

Choose SMPP when the send stream is sustained, the provider allocates a window you can size, and the team can operate a session: bind management, keep-alive, reconnect and PDU-level logs. Choose HTTP when the volume is modest, the team already runs secure web endpoints, and a callback fits the architecture. Choose both when the send path and the inbound path have different owners.

Whichever you choose, ask for the same evidence: a test route, the throughput allocation, the receipt format, the error-code list and the retry policy. The SMPP explainer covers the session, and the connection guide covers the path to production.

Write the choice down with the numbers: peak rate, window per bind, callback timeout and retry budget. A decision without those numbers is a preference. Review it when the peak or the team changes.

Check what you learned

A campaign runs at a steady 40 messages per second and receipts must arrive on the same transceiver session. Which transport fits?

SMPP with a transceiver bind, enough binds and a window sized for the rate. HTTP can carry the volume, but receipts arrive at a callback, not on the SMPP session.
The callback endpoint takes eight seconds to answer. What goes wrong?

The provider times out and retries, so the same event is delivered again. Answer quickly and process the event after the response.
Why is a silent bind harder than a dropped bind?

A dropped bind fails visibly. A silent bind looks open, so the client keeps sending until a timeout exposes it. Keep-alive traffic finds it earlier.

Answers are revealed on request. Nothing is scored, stored or sent.

FAQ

Can we run both?

Yes. Many platforms send over SMPP and receive callbacks over HTTP during migration.

Which is faster to integrate?

HTTP, usually in an afternoon; SMPP pays off once volume justifies a persistent session.

Which is more reliable?

Neither is reliable by itself. Reliability comes from the route, the retry policy and the operations around it.

Can HTTP handle high volume?

Yes, with concurrency, connection pooling and asynchronous callbacks. SMPP is usually more efficient for a sustained stream, because the session and the receipt channel are already open.

Do we need a static IP?

Often yes for SMPP, because the provider allowlists the client address. HTTP integrations usually rely on TLS and a key instead. Confirm the requirement before you build.

Sources

Terms you'll meet

Tools used

SMPP & DLR code decoder

Paste a command_status, the stat and err fields of a delivery report or a hex PDU to see what it means and what to check next.