SMPP, the Short Message Peer-to-Peer protocol, is how applications and the mobile network exchange SMS. If you send through an HTTP API, SMPP is probably still involved somewhere below you.
What does the protocol do?
It carries short messages between an application and a message centre, in both directions, over a connection that stays open.
The SMPP reference describes it as:
The SMPP (Short Message Peer-to-Peer) protocol is an open, industry standard protocol designed to provide a flexible data communications interface for the transfer of short message data between External Short Message Entities (ESME), Routing Entities (RE) and Message Centres (MC). It is a means by which applications can send and receive SMS messages to and from mobile devices. Applications do this using an SMPP connection to a Short Message Service Center (SMSC), SMS gateway, SMPP gateway or hub.
Three role names in one sentence, and they are worth separating because the vocabulary is where people get lost:
- ESME, the External Short Message Entity, is your application.
- MC or SMSC, the Message Centre, is the network element that stores and forwards the message toward the handset. What is an SMSC covers it.
- RE, a Routing Entity, is anything in between: an aggregator, a gateway, a hub.
How is it different from calling an HTTP API?
It is a session rather than a request.
An HTTP send is one request, one response, and no state between calls. SMPP is a TCP connection you bind with credentials and then hold open, exchanging binary operations across it. Sending is submit_sm; messages coming the other way, including delivery receipts, arrive as deliver_sm. The connection is bidirectional by design, which is why a receipt is a message to you rather than something you poll for.
That difference is the reason SMPP suits sustained volume. There is no per-request setup, the connection is already there, and throughput is a property of the session rather than of how fast you can open sockets. It is also the reason it is more work: you own reconnection, windowing, sequence numbers, and keeping the bind alive.
Why do people still choose it?
Volume, standardisation and independence, in that order. The reference's SMS gateways page is direct about the trade:
Short Message Peer-to-Peer (SMPP) is used as an access protocol, or SMS API, by SMS gateways worldwide. Other SMS APIs such as HTTP, SMTP and XML are also often offered. SMPP is preferable to these other SMS APIs because it is ideal where significant volumes of SMS are sent and/or received, when an industry standard protocol is preferable for development and maintenance purposes, or when vendor lock-in must be avoided.
The last clause is the one worth weighing. An HTTP API is a vendor's own shape, so moving between vendors means rewriting the integration. SMPP is the same protocol everywhere, so moving means repointing a connection. That matters at the scale where a migration is a project.
One caveat on sourcing, in the site's own words:
This domain was originally the home of the SMPP Developers Forum / SMPP Forum that later became the now disbanded SMS Forum. This site has no association with any legal owner of the protocol or successor organisation.
So it is the de facto reference rather than an official one, and the body that published the specification no longer exists.
Should I use it?
Probably not, and the reason is not that it is old.
For most senders an HTTP API delivers the identical message to the identical handset with none of the session management, and modern platforms expose everything SMPP would give you: delivery receipts as webhooks, inbound messages as events, throughput as a documented ceiling. What is an SMS API vs an SMS gateway covers what you are choosing between.
The cases where SMPP still earns its cost are narrow and identifiable: you are running sustained high volume where connection overhead is a real cost, you have existing SMPP infrastructure, or you need to hold your own connections to several providers for routing reasons. If none of those describes you, the protocol underneath your provider is an implementation detail you are better off not owning.