SMPP (Short Message Peer-to-Peer) is an industry-standard protocol used to exchange SMS traffic between external systems and messaging platforms through a persistent TCP connection.

Organizations typically adopt SMPP when they already operate with this protocol or require a direct, session-based integration model. It is commonly used in high-volume environments where persistent connectivity, controlled throughput, and low-latency submission are operational requirements.

Unlike REST-based integrations, SMPP maintains an open session between systems. Messages are submitted asynchronously, responses are returned independently, and delivery events are received separately. This architecture allows greater control over session behavior and message flow.

A standard SMPP setup involves three logical layers: the client application (ESME), the messaging platform acting as the SMSC layer, and the mobile network operator responsible for final handset delivery. While the transport mechanism differs from API integrations, all traffic is processed within the same core messaging infrastructure.

Requirements

Before requesting activation, the client’s system must support SMPP version 3.4. Other protocol versions are not supported.

Connectivity must be established over secure TCP using TLS encryption.

From a session management perspective, the system must allow configuration of the bind type. This may be Transmitter (TX), Receiver (RX), or Transceiver (TRX), depending on the service model. The client must also support window-based flow control, configurable enquire_link intervals to maintain session health, timeout handling, and automatic reconnection logic in case of network interruption.

Proper message handling is equally important. The system must support GSM 7-bit encoding and UCS2 encoding for Unicode content. It must be capable of handling long messages through concatenation and must parse delivery receipts when they are enabled.

From an infrastructure standpoint, the client must ensure outbound connectivity to the assigned SMPP host and port. Credentials must be securely stored, and sufficient logging must be implemented to allow troubleshooting of bind attempts, submission responses, and delivery events.

Although SMPP 3.4 defines session-based and asynchronous behavior, it is important that the client implementation properly supports these mechanisms. Your system must:

Secure TCP Connectivity over TLS: All SMPP traffic must be wrapped in a TLS tunnel for encryption (Standard SMPP 3.4 is clear-text by default).
Maintain Active Sessions (Enquire Link): Implement the enquire_link PDU as a heartbeat mechanism to keep the connection alive. A 30-second interval is recommended to prevent intermediate firewalls or the SMSC from silently closing idle sessions.
Support Asynchronous Message Submission: SMPP is not an HTTP request/response protocol. Your application must allow multiple submit_sm requests to be sent without waiting for each corresponding submit_sm_resp. Implementing synchronous behavior will significantly reduce throughput.
Allow Bind Type Configuration: The client must be configurable to bind as TX (Transmitter), RX (Receiver), or TRX (Transceiver), depending on whether the integration handles MT, MO, or bidirectional traffic.

Integration Request Process

To initiate SMPP connectivity, the client must contact their Account Manager and formally request activation.

Once the request is received, an onboarding form will be shared. This form collects the technical parameters required to configure the connection securely and correctly.

The client must confirm:

SMPP Version (3.4)
Desired bind operation (TX - Transmitter, RX - Receiver, or TRX - Transceiver)
Public IP address(es) that will originate the connection
Service type (MT - Outbound messages sent from your system to end users, MO - Inbound messages received from end users, or Both, including Delivery Receipts if required)

📘
NOTE
If Delivery Receipts (DLR) are required, this must be specified during the onboarding stage.
A Delivery Receipt is a network-generated status notification that indicates the outcome of a submitted message after it has been processed by the mobile carrier. It is separate from the initial submission acknowledgment returned by the SMPP session.
Delivery receipt availability may vary depending on country regulations and carrier capabilities.
For a complete list of possible SMS delivery status, refer to the SMS Status section.
In Colombia, most delivery report (DLR) statuses are not supported due to carrier-level restrictions. Only the following statuses are available:
REJECTD: The carrier rejected the message before attempting delivery to the end user.
ENROUTE: Messangi successfully processed the message and handed it off to the carrier for delivery to the recipient’s mobile device.

Credential Provisioning

Once the onboarding form is validated, connection credentials will be provisioned.

System_ID
Password
Source Address
TON/NPI Source
TON/NPI Destination
Maximum allowed TRX sessions

These credentials must be configured in your SMPP client application exactly as provided.

The maximum TRX sessions parameter defines the number of concurrent connections allowed. Exceeding this limit may result in rejected bind attempts.

Credentials must be handled securely and stored according to your organization’s internal security policies.

Once the SMPP session is successfully configured and operational, the platform has the capability to reflect message activity (submissions and delivery events) within the Communications Platform, including logs, reports, and dashboards. The SMPP Traffic (Analytics & Reporting) section outlines how SMS activity can be reviewed and analyzed.

📘
NOTE
If you are interested in activating these reporting capabilities should coordinate with your Account Manager to review availability and configuration options.