Connecting over SMPP and HTTP
Take a test route to production without breaking binds, windows or receipts: bind, throughput, keep-alive, encoding, callbacks and failure handling.
A production messaging connection is an operating contract, not just an endpoint. SMPP adds bind state, a throughput window, keep-alive traffic and receipts on the session. HTTP adds per-request authentication and callbacks. The guide turns both into a sequence from test to production.
On this page
Bind state is the first thing to own
A bind is a session with a declared direction. A transmitter submits, a receiver accepts inbound messages and receipts, and a transceiver does both. The provider issues credentials for the bind type you need, and the client must treat the bind as state: opening, bound, throttled, reconnecting or closed. A client that assumes the bind is always up will lose messages at the first drop.
Track the bind state explicitly. Log every bind request and response, the interface version, the system ID and the error code. On a drop, reconnect with backoff and do not replay in-flight submits until you know whether the message center accepted them. The message ID from submit_sm_resp is the only reliable way to tell.
The bind and the first submit
- Application (ESME)
- bind_transceiver Open the session
- SMSC
- submit_sm_resp Accepted for delivery
- Delivery receipt
Text description
The client sends a bind request and receives a bind response. It submits a message with submit_sm and receives submit_sm_resp with a message ID. Later the message center sends a deliver_sm PDU with the receipt, and the client answers with deliver_sm_resp. An unbind closes the session.
Window, heartbeat and encoding
The window is the number of outstanding requests the message center will accept on one bind. Keep the in-flight count under it and let the window drain before a burst. A throttled submit is a signal to slow down; retrying at the same rate fills the queue and turns one slow message into a backlog. Size the bind count from the peak rate, not from the monthly average.
Keep-alive exchanges tell both ends that the session is alive. Send enquire_link on a schedule and close a session that stops answering. For encoding, send GSM-7 where the content allows and UCS-2 otherwise. A single character outside the GSM-7 set changes the whole message to UCS-2 and can change the segment count. Test the exact template, including the variable values.
Delivery receipts
A receipt arrives asynchronously as a deliver_sm PDU. It carries the original message ID, a state such as delivered, expired, undelivered or unknown, and often a network code. Match it by message ID and store the state with the message record. Do not match by arrival order, and do not treat a missing receipt as a failed message.
Receipt formats differ. Newer message centers use a message_state tag-length-value field; older ones put key-value text in the short message field. Parse both. Normalize the states your application needs and keep the raw code, so a support case can be traced back to what the network said.
Failure modes and the first response
| Symptom | Likely cause | First check |
|---|---|---|
| Bind rejected | Wrong credentials, wrong bind type or interface version | Read the bind response code and the interface version |
| Timeouts rising | Window exceeded or a slow route | Check the in-flight count and the response codes before retrying |
| Bind open, no replies | Session is dead or the client stopped keep-alive | Send enquire_link, then reconnect with backoff |
| Receipt missing | The receipt never reached the handler | Check the session log and the message ID before resending |
| Wrong characters | GSM-7 content sent as UCS-2, or the reverse | Check the data coding and the segment count |
| Callback timeout | The endpoint is slow or unreachable | Answer fast, process asynchronously, verify the signature |
The response order matters: observe, then change one variable.
From test route to production
-
Bind to the test route
Use the test credentials and the bind type you will run in production. Confirm the bind response and the interface version.
-
Send the real templates
Test the content you will launch, including links, variables and the longest message. Record the encoding and the segment count.
-
Read the receipts
Match every receipt by message ID. Confirm the states and the error codes your application will receive.
-
Test the failure path
Send to an invalid number, a full handset and a barred service. Confirm the receipt states and the application's handling.
-
Size the window
Run a peak-rate test and confirm the in-flight count stays under the window. Add a bind if it does not.
-
Turn on monitoring
Alert on bind state, submit latency, receipt latency and the receipt-state mix. Name the person who acts on each alert.
-
Switch production traffic
Move a small share first, compare the receipts with the test, then increase. Keep the test route available as a fallback.
HTTP authentication and callbacks
An HTTP integration authenticates each request with the key issued at onboarding. Rotate the key before it expires and keep the old key valid for the overlap. A send returns an accepted response with a message ID; the receipt and any inbound message arrive at your callback URL.
The callback endpoint must verify the signature, answer quickly and process the event after the response. A slow endpoint causes retries, and retries cause duplicates unless the handler is idempotent. Keep the endpoint reachable through certificate and DNS changes, and alert when the callback failure rate rises. The SMPP explainer covers the session; the transport comparison covers the choice.
FAQ
Which SMPP version should we use?
How many binds do we need?
Should the callback answer before processing?
What if a receipt never arrives?
How do we test a failure?
Related
- Global A2P sender-ID playbook
How sender IDs work across markets: alphanumeric, numeric and short-code paths, registration expectations and country examples.
- A2P SMS
Application-to-person SMS is traffic an application sends to a handset, such as a verification code or a transaction alert, via a registered sender.
- DLR
A delivery receipt reports the mobile network's status for a sent SMS, such as delivered, expired, rejected or unknown.
Adjacent to what we offer
We explain this here because it affects how you use our service.