SMPP CONNECTION

SMPP Connection for Business SMS

Connect your platform through the industry-standard protocol for high, sustained traffic, with persistent sessions and delivery reports over the same connection.

Request an SMPP connection

What SMPP is

SMPP (Short Message Peer-to-Peer) is the open protocol the telecom industry uses to exchange SMS between applications and message centers. Version 3.4 is the most widely used. In an SMPP connection your platform acts as an ESME (External Short Message Entity) and keeps a persistent TCP session with the message center, over which it sends messages and receives delivery reports without opening a new connection per send.

Bind types

Bind	What it allows	Typical use
`bind_transmitter`	Send only (submit_sm)	Systems that split sending and receiving into separate sessions
`bind_receiver`	Receive only (deliver_sm): delivery reports and inbound messages	Processes dedicated to reconciling DLRs or receiving replies
`bind_transceiver`	Send and receive on the same session	The most common choice for new integrations

Protocol messages worth knowing

submit_sm: sends a message; submit_sm_resp returns the message_id.
deliver_sm: delivers a delivery report or inbound message (MO); acknowledge it with deliver_sm_resp.
enquire_link: keeps the session alive and detects drops.
unbind: closes the session cleanly.

Throughput, windowing and flow control

SMPP capacity is expressed in messages per second (TPS) and depends on the number of sessions and the window: how many submit_sm requests can be outstanding at once. When agreed capacity is exceeded, the message center replies with flow-control errors such as ESME_RTHROTTLED; your platform should slow down and retry instead of disconnecting. At Grupo Tecnophone, sessions and capacity are sized per project.

Delivery reports over SMPP

Request the final status through the registered_delivery field of submit_sm. The report arrives as a deliver_sm referencing the original message_id and, by convention, includes text like this:

id:a1b2c3d4 sub:001 dlvrd:001 submit date:2610121432 done date:2610121432 stat:DELIVRD err:000

Status	Meaning
`DELIVRD`	Delivered to the handset
`UNDELIV`	Undeliverable (non-existent, inactive or network-rejected number)
`EXPIRED`	Validity period expired, e.g. phone off
`REJECTD`	Rejected before delivery was attempted
`ACCEPTD`	Accepted without final delivery confirmation
`UNKNOWN`	Status could not be determined

SMPP or REST API

If your use case is an application sending OTPs, alerts or notifications, the REST SMS API is usually the fastest route. SMPP makes sense when you already run a gateway or sustained volume justifies it. See also delivery reports and webhooks.

Operating best practices

Send enquire_link periodically and reconnect with progressive backoff.
Respect the agreed window and capacity; treat throttling as a signal to slow down.
Log every message_id to reconcile reports and billing.
Always acknowledge each deliver_sm to avoid duplicate reports.
Monitor UNDELIV and EXPIRED by destination to clean your database.

Connection parameters, credentials and allowlisted IPs are defined during onboarding. Talk to our technical team about your project.

Frequently asked questions about SMPP

What is SMPP?

The industry-standard protocol to exchange SMS between applications and message centers through persistent TCP sessions. Version 3.4 is the most widely used.

What is the difference between transmitter, receiver and transceiver?

Transmitter only sends, receiver only receives delivery reports and inbound messages, and transceiver does both on the same session.

What does TPS mean?

Messages per second: a connection’s sending capacity, depending on sessions, window and what is agreed with the provider.

When does SMPP make more sense than a REST API?

When traffic is high and sustained or your platform already runs an SMPP gateway. For applications sending OTPs and notifications, a REST API is usually simpler.