SMPP Connectivity & SMPP Interconnect

Q: How do I keep the session alive?

Send enquire_link at a regular interval and answer ours. A session that stops responding is closed and must re-bind.

What is SMPP connectivity?

SMPP (Short Message Peer-to-Peer) is the industry protocol that external short message entities (ESMEs), such as aggregators and applications, use to exchange SMS with a short message service centre (SMSC) or SMS gateway over TCP/IP. An SMPP connection is a long-lived session, called a bind, over which the client submits messages and receives delivery receipts.

What we support

Item	Detail
Protocol	SMPP 3.4 over TCP/IP
Bind types	Transceiver, or separate transmitter and receiver
Access control	System ID and password, accepted only from your registered IP addresses
Throughput	Messages per second agreed per account
Delivery receipts	Returned as `deliver_sm` on a receiver or transceiver bind
Alternative	HTTP submission for simpler integrations

Bind types and credentials

Every session starts with a bind request carrying your system ID and password. We issue credentials per account and accept binds only from the IP addresses you register. The number of simultaneous binds per account is agreed during onboarding.

Throughput and windowing

Throughput is measured in messages per second per account. Your client can send several messages before waiting for responses (the window); keep the window and send rate within the agreed limits. If you exceed them, we return a throttling error (ESME_RTHROTTLED); back off and retry.

Delivery receipts and error codes

Request a delivery receipt on each submit_sm by setting registered_delivery. The receipt arrives later as a deliver_sm with the message ID and final state, such as delivered, undeliverable or expired. Errors at submission time come back immediately in the submit_sm_resp status field, for example invalid destination address or invalid source address.

Failover

We recommend at least two binds, so traffic continues if one session drops. On our side, traffic to each destination can move between approved routes when quality falls.

Onboarding steps

Account request. Send expected throughput, destinations, traffic type and your source IP addresses.
Credentials. We issue a system ID, password and connection details, and open access for your IPs.
Test traffic. Test messages to agreed numbers confirm delivery, sender ID handling and receipts.
Go-live. Throughput limits are set and live traffic starts.

Security on SMPP connections

SMPP accounts are protected by IP access lists, credentials and per-account throughput limits, and traffic is checked for sender ID and content policy breaches. Operators who want the same controls on their own SMSC connections can use our SMPP firewall.

Want to run SMPP connections for your own customers? See our Enterprise SMPP Gateway.

New to the protocol? Read What is SMPP?

Frequently asked questions

Which SMPP version do you support?

SMPP 3.4, the version used by almost all A2P messaging connections today.

Should I use a transceiver bind?

A transceiver bind sends and receives on one session and is the simplest choice. Separate transmitter and receiver binds are also supported where your platform needs them.

How is throughput limited?

Each account has an agreed messages-per-second limit. Messages above it receive a throttling error, and your system should slow down and retry rather than reconnect.

How do I keep the session alive?

Send enquire_link at a regular interval and answer ours. A session that stops responding is closed and must re-bind.