SMPP Messaging Integration
Use SMPP (Short Message Peer-to-Peer) to exchange SMS traffic with the messaging platform over a persistent TCP connection.
SMPP is suited to high-volume integrations that need persistent connectivity, controlled throughput, and low-latency message submission. Your client application acts as the ESME (External Short Messaging Entity), the messaging platform acts as the SMSC (Short Message Service Center), and the mobile network operator delivers messages to handsets.
Unlike a REST integration, SMPP keeps a session open. You submit messages asynchronously, receive submit_sm_resp responses independently, and receive delivery events separately.
Requirements
Complete these requirements before requesting SMPP activation:
- Use SMPP version 3.4. Other protocol versions are not supported.
- Establish connectivity over secure TCP using TLS encryption. Standard SMPP 3.4 uses clear text by default, so wrap all SMPP traffic in a TLS tunnel.
- Configure the required bind type: Transmitter (TX), Receiver (RX), or Transceiver (TRX). Select TX for MT traffic, RX for MO traffic, or TRX for bidirectional traffic.
- Implement window-based flow control so that you can send multiple
submit_smrequests without waiting for eachsubmit_sm_resp. Processing requests synchronously reduces throughput. - Send the
enquire_linkPDU to maintain the session. Use a 30-second interval to help prevent firewalls or the SMSC from closing an idle session. - Handle session timeouts and reconnect automatically after a network interruption.
- Support GSM 7-bit encoding and UCS2 encoding for Unicode content. Support concatenation for long messages and parse delivery receipts when enabled.
- Allow outbound connectivity to the assigned SMPP host and port. Store credentials securely and log bind attempts, submission responses, and delivery events for troubleshooting.
Integration Request Process
- Contact your Account Manager to request SMPP activation.
- Complete the onboarding form that your Account Manager provides.
- Confirm the following technical details:
- 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)
NOTEIf 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: The platform successfully processed the message and handed it off to the carrier for delivery to the recipient’s mobile device.
Credential Provisioning
After the onboarding form is validated, you will receive the following connection credentials:
- System_ID
- Password
- Source Address
- TON/NPI Source
- TON/NPI Destination
- Maximum allowed TRX sessions
Configure these values in your SMPP client exactly as provided and store them according to your organization’s security policies.
Maximum allowed TRX sessions is the number of concurrent connections you can establish. Exceeding this limit can cause bind attempts to be rejected.
After your SMPP session is operational, review message submissions and delivery events in the Communications Platform logs, reports, and dashboards. See SMPP Traffic (Analytics & Reporting).
Updated 13 days ago
