What is SMPP? The SMS protocol explained with binds, PDUs and examples

What is SMPP?

SMPP, short for Short Message Peer-to-Peer, is a protocol for exchanging SMS between two systems over a long-lived TCP connection. It was designed for the link between a business or aggregator and the short message centre, or SMSC, of a mobile operator. If a message crosses between telecom companies, there is a good chance SMPP carried part of the journey.

Most developers never need to speak it directly, because a REST interface hides it. But when volumes grow, when you connect software that already uses it, or when you want to understand a delivery problem at the lowest level, knowing how SMPP works is useful. This guide covers sessions, the main messages, throughput controls and the practical choice between SMPP and an API. If you want the simpler route first, read what an SMS API is.

How an SMPP session works

Unlike HTTP, where each request opens and closes, SMPP keeps one connection open. Your system is called the ESME, an external short messaging entity. It connects to the provider's SMSC and exchanges small binary packets called PDUs. The specification is published as the SMPP protocol specification, and the background is summarised on Wikipedia.

1. Connect and bind. Open TCP, then send a bind PDU with your system ID and password. The provider answers success or an error.
2. Submit messages. Send submit_sm PDUs. Each gets a submit_sm_resp that carries the provider's message id.
3. Receive receipts and replies. The provider sends deliver_sm PDUs for delivery receipts and for messages coming from handsets. You acknowledge each one.
4. Stay alive. Send enquire_link at intervals. If answers stop, treat the session as dead and reconnect.
5. Unbind cleanly. Send unbind before disconnecting so in-flight messages are accounted for.

The main SMPP messages

Every PDU carries a command id and a sequence number. You match each response to its request by that number, which is how a single connection can have many messages in flight at once.

Bind types

Throughput: windows, TPS and long messages

SMPP is fast because you do not wait for each response before sending the next message. The window size is the number of unanswered submit_sm PDUs you may have outstanding. A window of one is slow, because you send, wait and repeat. A window of fifty lets you keep the pipe full. Your provider also sets a rate limit in messages per second, and exceeding it brings throttling errors. See our SMPP documentation and limits for the values on your account.

Long messages need extra care. A message over 160 characters in the standard alphabet is split into segments, each carrying a header so the handset can reassemble them. The cost and the count of segments depend on the encoding, which is why we cover it in our guide to segments, encoding and cost. In SMPP you either send each segment yourself or use the message payload field and let the provider split it, depending on what the provider supports.

A conceptual session in text

-> bind_transceiver     system_id=acme  password=****   seq=1
<- bind_transceiver_resp status=OK                        seq=1
-> submit_sm            from=TELNXO to=919812345678 text=...  seq=2
<- submit_sm_resp       status=OK  message_id=8f3a2c      seq=2
<- deliver_sm           receipt for 8f3a2c: DELIVRD       seq=7
-> deliver_sm_resp      status=OK                         seq=7
-> enquire_link                                           seq=8
<- enquire_link_resp                                      seq=8

This is a simplified view for learning; a real library builds the binary packets for you. Popular open-source clients exist in most languages, and the SDK list points to supported options.

SMPP vs REST API

A good rule is to start with REST and move to SMPP when a number proves you need it, such as a sustained rate your REST client cannot reach, or a vendor product that supports only SMPP. Our SMS gateway guide explains where the protocol sits in the wider path, and the SMS product page lists connection options.

Operating an SMPP connection reliably

• Reconnect with backoff. If the link drops, wait a little, then try again, doubling the delay up to a limit.
• Use enquire_link. It is the only way to notice a half-dead connection that still looks open.
• Respect the window. Never exceed the agreed number of unanswered messages or the rate limit.
• Persist before you send. Save each message with its sequence number and the returned id so a crash does not lose track of it.
• Use TLS and IP allow-lists. The protocol itself sends credentials in a simple form, so protect the transport.
• Match receipts carefully. A receipt references the provider's message id; store it when you get the submit response.

Receipts can be missing or late on some routes. Our notes on delivery reports and why an SMS is not delivered explain what to expect.

Common SMPP errors and what they mean

Security and testing

SMPP was designed in a period when networks were more trusted than they are today, so the protocol itself offers little protection. Credentials travel in the bind PDU, and messages are not encrypted unless you wrap the connection. In practice that means running SMPP over TLS where your provider supports it, restricting the connection to known IP addresses, rotating the password and giving each system its own account so you can revoke one without stopping the rest.

Test in stages. Begin with a single message to your own phone and look at each PDU in your client log. Then send a small batch to see how receipts arrive and whether the sequence numbers match. Finally, run a load test at the rate you expect, watching for throttling and for the window filling up. A test that includes a forced disconnect shows whether your reconnect logic really works, which is the part that usually fails first in production.

SMPP is not harder than HTTP, only different: you manage a connection instead of a call.