SMPP SMS Gateway


Bridge between REST and SMPP for sending SMS

Use the simple and powerful REST API of the REST-SMPP Bridge and let it take care of getting the best out of your SMPP account. This REST HTTP-to-SMPP service allows you to offload the heavy lifting associated with using SMPP with an SMSC or SMS gateway, allowing your application to be easier to develop and maintain, and less demanding on your infrastructure.

Hundreds of thousands of SMS can be sent with a single API call that takes a handful of seconds. You (or your customers) make a REST API call to send messages, and the service handles all the complexities of SMPP for you. It requires no account from us or pre-configuration to use.

Get an SMPP account from your favourite mobile messaging provider and use it for sending SMS, without needing to support SMPP in your application. Instead, use the simple and powerful REST API of the REST-SMPP Bridge and let it take care of getting the best out of your SMPP account.

REST-SMPP Bridge is a smart service that takes care of the heavy lifting aspect of expediently and reliably submitting messages for delivery, handling failure situations and receiving delivery receipts.

How it works

To send a message to mobiles, you make a REST API call to the service endpoint to submit your message. In this API call, you include the SMPP account details of the SMS gateway or SMSC, set options for controlling message submission, the message to be sent (including source address, flags, validity, scheduled delivery time and data coding), and the list of destination mobiles. The list of destination mobiles can contain up to 250,000 numbers.

On receiving your message submission, the service will return a transactionID, and a messageID for each destination mobile number being sent the message. A worker process dedicated to your submission will then be created to start work on send your messages. This worker will establish one or more SMPP binds using the SMPP account details you provided and commence submission of your message to the SMS gateway or SMSC. The window size, TPS and quantity of binds can be set in message submission options of your API call. If delivery receipts were requested, then an SMPP transceiver bind (SMPP v3.4 and v5) or transmitter and receiver binds (SMPP v3.3) will be made, otherwise an SMPP transmitter bind will be made.

Delivery receipts will be received by the worker and the status of message delivery for each mobile will be updated in the database. This status can be queried by a REST API call.

The following operations are available using the service REST API:

  • submit - message submission for delivery to one or more mobile numbers
  • query / report / status - query the status of message delivery for a previous message submission (query whole submission or subset of submission)
  • cancel - cancel a previous message submission in whole (all mobile numbers) or in part (some mobile numbers)


REST calls can be made to the REST-SMPP bridge to send SMS to mobiles. There are two methods for sending messages: "Message" and "SMS".

The "SMS" method is an immediate pass-thru of the message from REST to SMPP, with the "messageID" containing the message ID from the sumbit_sm_resp returned by your provider.


Submitting a message to REST-SMPP Bridge service with the REST API
Example using cURL, Node.js, Python, PHP

Submit message for delivery and get transaction ID for submission. This request submits a message for delivery to three mobile numbers (up to 250,000 mobile numbers can be submitted in one request). The submit window size is set to 10 messages and the number of binds that will be used is set to 1.

This request will result in:

  • The service returning a transaction ID for this request, along with a message ID for each destination mobile number that will be sent the message.
  • A single transceiver (TRX) bind being established by the worker process to using a TLS connection.
  • Three submit_sm PDUs being sent, and then receiving the corresponding submit_sm_resp PDUs.
  • Delivery receipts being received by the worker process for each of the three messages once they reach completion (e.g. delivered or undelivered).

JSON request:

    "smpp_account_config": {
        "host": "",
        "port": 8775,
        "use_tls": true,
        "smpp_version": 5,
        "system_id": "SYSTEMID",
        "password": "PASSWORD"
    "submit_options": {
        "windowSizeSubmitSM": 10,
        "quantityBindSessions": 1
    "message": {
        "source_addr": "MelroseLabs",
        "source_addr_ton": 5,
        "source_addr_npi": 0,
        "registered_delivery": 1,
        "short_message": {
            "text": "Melrose Labs engineer great communication services."
    "destinations": [


curl \
	--header 'x-api-key: [API_KEY]' --header 'Content-Type: application/json' \
	--data-raw '{"smpp_account_config":{"host":"","port":8775,"use_tls":true,"smpp_version":5,"system_id":"SYSTEMID","password":"PASSWORD"},"submit_options":{"windowSizeSubmitSM":10,"quantityBindSessions":1},"message":{"source_addr":"MelroseLabs","source_addr_ton":5,"source_addr_npi":0,"registered_delivery":1,"short_message":{"text":"Melrose Labs engineer great communication services."}},"destinations":["447968847040","15005552361","390611100000"]}'


{ "transactionID": "41123b82-9f43-4ff8-8c01-0b4ce2bced6f", "messageID":["abcd0001","abcd0002","abcd0003"] }


var request = require('request');
var options = {
  'method': 'POST',
  'url': '',
  'headers': {
    'x-api-key': '[API_KEY]',
    'Content-Type': 'application/json'
  body: JSON.stringify({"smpp_account_config":{"host":"","port":8775,"use_tls":true,"smpp_version":5,"system_id":"SYSTEMID","password":"PASSWORD"},"submit_options":{"windowSizeSubmitSM":10,"quantityBindSessions":1},"message":{"source_addr":"MelroseLabs","source_addr_ton":5,"source_addr_npi":0,"registered_delivery":1,"short_message":{"text":"Melrose Labs engineer great communication services."}},"destinations":["447968847040","15005552361","390611100000"]})
request(options, function (error, response) { 
  if (error) throw new Error(error);
  console.log(response.body); // response is of type application/json


{ "transactionID": "41123b82-9f43-4ff8-8c01-0b4ce2bced6f", "messageID":["abcd0001","abcd0002","abcd0003"] }


import requests
import json

url = ""
payload = {
	{"smpp_account_config":{"host":"","port":8775,"use_tls":true,"smpp_version":5,"system_id":"SYSTEMID","password":"PASSWORD"},"submit_options":{"windowSizeSubmitSM":10,"quantityBindSessions":1},"message":{"source_addr":"MelroseLabs","source_addr_ton":5,"source_addr_npi":0,"registered_delivery":1,"short_message":{"text":"Melrose Labs engineer great communication services."}},"destinations":["447968847040","15005552361","390611100000"]}
headers = {
  'x-api-key': '[API_KEY]',
  'Content-Type': 'application/json'

response = requests.request("POST", url, headers=headers, data = json.dumps(payload))

# response is of type application/json


{ "transactionID": "41123b82-9f43-4ff8-8c01-0b4ce2bced6f", "messageID":["abcd0001","abcd0002","abcd0003"] }


$data = {"smpp_account_config":{"host":"","port":8775,"use_tls":true,"smpp_version":5,"system_id":"SYSTEMID","password":"PASSWORD"},"submit_options":{"windowSizeSubmitSM":10,"quantityBindSessions":1},"message":{"source_addr":"MelroseLabs","source_addr_ton":5,"source_addr_npi":0,"registered_delivery":1,"short_message":{"text":"Melrose Labs engineer great communication services."}},"destinations":["447968847040","15005552361","390611100000"]}

$curl = curl_init();

curl_setopt_array($curl, array(
  CURLOPT_URL => "",
    "x-api-key: [API_KEY]",
    "Content-Type: application/json"

$response = curl_exec($curl);


echo $response; // response is of type application/json


{ "transactionID": "41123b82-9f43-4ff8-8c01-0b4ce2bced6f", "messageID":["abcd0001","abcd0002","abcd0003"] }

The transactionID is used to uniquely identify your submission and it should be kept secure. The transactionID can be used to perform cancel and query operations on your submission.

Data Protection and Data Retention

We operate on the following principles:

  • Customer data is encrypted when at rest and when in motion. Exception is when customer elects to use non-encrypted SMPP.
  • Customer data (e.g. account details, message content, telephone numbers) is only used to provide the REST-SMPP Bridge service to the customer.
  • Data is only kept for as long as necessary to provide service to the customer, ensure that we can support the customer, and be able to fulfil our legal and regulatory obligations.
  • Data relating to individuals (e.g. destination mobile numbers) is converted to anonymised form once no longer required.


The REST-SMPP Bridge service has the following limits:

Bind quantity20 bindsMaximum number of SMPP binds that a worker process will establish for processing a message submission. Default: 1
Submit Window Size8,000Maximum number of SMS that have been sent by worker process and are awaiting submit_sm_resp from SMSC or SMS gateway. Default: 10
Destination numbers250,000Maximum number of destination mobile numbers that an individual submission can be made to.
Worker process lifetime7-daysMaximum duration of time that a single submission's worker process will maintain SMPP binds to SMSC or SMS gateway.
Submission status lifetime90-daysMaximum duration of time that the status of submissions can be queried.
Delivery status lifetime60-daysMaximum duration of time that the status of delivery to an individual mobile can be queried.

Duration limits are from the moment the message is submitted to the service.


The REST-SMPP Bridge service is provided free-of-charge.

Service snapshot

  • High performance, fault tolerant SMS handling with automatic scaling
  • Single REST API call to send thousands of messages
  • 5000 SMS/sec (MT and MO SMS)
  • SMPP v3.x, v5; SMPP over TLS
  • Delivery receipts supported
  • Use with any SMPP account (BYO)


Find out more...

Please provide your name.
Please provide a valid company name.
Please type your message.
Please provide a valid email address.