An application can submit a text before the recipient's phone becomes reachable. An SMPP connection carries that submission and the later operations that report what happened.
What does the connection carry?
SMPP carries message submissions, incoming messages and delivery reports between connected systems.
Your application can connect to a gateway that routes traffic onward. It can also connect directly to a message center where the provider supports that arrangement.
The SMPP reference describes those roles and operations. A message center stores texts and forwards them toward recipients.
A gateway between your application and the center adds another routing step. The protocol name alone does not tell you how many systems handle the message.
How does an SMPP session work?
Your client opens a connection. It authenticates the session and keeps it available for message operations.
The authentication step is called a bind. A transmitter session sends messages. A receiver session receives them. A transceiver session supports both directions.
Use the session type your workflow requires. A send-only connection cannot replace a receiving session when you need incoming operations.
Your client must recover from connection loss. It must also acknowledge operations it receives. Track requests awaiting responses so a delayed response is matched to the right request.
Does a submission response prove delivery?
A submission response reports whether the connected service accepted the submission, not whether the phone received the text.
The submit_sm operation submits a message. Its corresponding submit_sm_resp reports the result of that request.
Incoming messages and delivery receipts can arrive through deliver_sm. The delivery-receipt reference explains receipt operations and their contents.
Keep the submission result separate from the delivery result in your application. A message can be accepted and later fail because the recipient remains unreachable.
What changes when I use an HTTP API instead?
HTTP exposes request and response operations without requiring your application to manage an SMPP bind.
Your application still needs to handle retries. It must also process later delivery outcomes. HTTP does not turn a carrier's asynchronous delivery into a synchronous guarantee.
With Bird, you submit through POST /v1/sms/messages and track the returned message identifier. The sending guide explains the 202 acceptance response. SMS events supplies the subsequent delivery reports.
Those API responsibilities are separate from managing an SMPP connection to a provider. APIs and gateways explains the layers.
Does using SMPP make providers interchangeable?
Providers are not interchangeable just because they share a protocol. They can support different operations, encodings and limits.
Test the capabilities your application uses before moving traffic. A successful bind does not establish that every required operation works on that provider.
The gateway reference recommends testing implementation support and performance. Keep your delivery checks when changing connections, rather than treating a new endpoint as a complete migration.
When should I choose SMPP?
Choose SMPP when an existing system needs a persistent bind or SMPP-specific incoming operations.
- Use HTTP for a new application with no specific SMPP requirement.
- Use SMPP when an existing system needs a persistent bind or SMPP-specific incoming operations.
- Test provider support and delivery outcomes before moving production traffic.
In short
Your client manages a session.
It authenticates the connection and handles recovery when that connection fails.
Submission and delivery are different operations.
A successful submission response does not establish that the handset received the message.
Support varies between providers.
Test operations, encoding and capacity rather than assuming the protocol makes providers interchangeable.
HTTP can avoid SMPP session management.
HTTP avoids managing an SMPP bind, while your application still handles delivery events.