SMS API vs SMPP: Which Connection Should You Use?

This guide is for engineers and technical leads deciding how to connect to an SMS provider: through an HTTP/REST SMS API, through SMPP, or both. It explains how the two really differ on the wire and in operations, so you can pick the right interface for each kind of traffic and plan a migration if you outgrow your first choice.

For a broader view of integration patterns, including webhooks and idempotency, see our messaging API integration guide.

What is the difference between an SMS API and SMPP?

A REST SMS API sends each message as a separate HTTPS request and returns a message ID. SMPP (Short Message Peer-to-Peer) keeps one long-lived, authenticated session open and exchanges binary messages, called PDUs, over it in both directions. REST optimises for simplicity; SMPP optimises for sustained SMS volume.

How does a REST SMS API work?

You make an HTTPS POST with a token and a JSON body, and the provider answers with an ID. Each request is independent, so you can send from any server, function or container without managing a connection.

A typical send with our API looks like this:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

The response is 200 OK with the message ID as plain text. The final status arrives later at your webhook as SUBMITTED, SENT, DELIVERED, FAILED or REJECTED. Field names and options are in the SMS API reference.

Strengths of REST:

• Familiar tooling: any language, any HTTP client, standard status codes as defined in RFC 9110.
• Easy security: TLS everywhere and a token in the Authorization header.
• Bulk without connections: upload a file of recipients in one request instead of opening a session.
• One API for many channels: the same pattern sends WhatsApp templates or RCS cards.

Limits of REST: each message, or each batch, costs an HTTP round trip, and you will meet a requests-per-second limit before you meet any operator limit. For most application traffic this never matters.

How does SMPP work?

SMPP is a binary protocol defined by the SMPP v3.4 specification, published by the SMPP Developers Forum (later the SMS Forum) and still the most widely deployed version. Your system, called the ESME (External Short Message Entity), connects to the provider's SMSC (Short Message Service Centre) and opens a session called a bind.

Bind types

• Transmitter (TX), using bind_transmitter: submit messages only.
• Receiver (RX), using bind_receiver: receive delivery receipts and inbound messages only.
• Transceiver (TRX), using bind_transceiver: both on one session. This is the usual choice.

Session lifecycle

1. Open a TLS connection to the host and port your provider gives you.
2. Send bind_transceiver with your system_id and password, and wait for a response with command_status 0.
3. Send messages with submit_sm. Each submit_sm_resp returns a message_id.
4. Receive delivery receipts as deliver_sm and answer each one with deliver_sm_resp.
5. Send enquire_link periodically while idle so both sides know the session is alive.
6. Close with unbind and wait for unbind_resp.

Every PDU carries a sequence number, and responses carry the same number, which is how you match a submit_sm_resp to the message you sent. Our SMPP documentation covers each step with our settings.

What is SMPP windowing and why does it matter?

Windowing means sending several submit_sm PDUs before their responses come back. The number of unacknowledged PDUs allowed in flight is the window. It is the main reason SMPP sustains higher throughput than one-request-at-a-time HTTP.

With a window of 1, your client sends one message, waits a full round trip for the response, then sends the next. Throughput is capped by network latency, not by your agreed rate. With a larger window, the connection stays busy while responses arrive.

Rules of thumb:

• Use the window size your provider agrees with you, and never exceed it; extra PDUs may be rejected.
• Respect the agreed rate per bind. If you receive ESME_RTHROTTLED, slow down and retry with backoff.
• Track outstanding sequence numbers so a disconnect does not lose track of which messages were accepted.
• Scale with more binds, up to the number agreed for your account, rather than with an ever-larger window.

The default limits for our REST API and SMPP binds are listed in errors and limits; your account's limits are confirmed when access is provisioned.

How do delivery receipts differ?

On REST, the provider posts a JSON event to your webhook. On SMPP, the receipt arrives as a deliver_sm PDU on the session, with the receipt bit set in esm_class. Both are asynchronous; neither 200 OK nor submit_sm_resp means the handset received the message.

The SMPP v3.4 specification gives the receipt text format as an example and leaves the exact format to the SMSC vendor, but most providers follow it:

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

If your systems consume both interfaces, map SMPP states to one status model. A typical mapping:

Two practical differences matter more than format:

• Acknowledgement. An SMPP client must answer every deliver_sm. Unacknowledged receipts are re-sent and can slow the bind. A webhook handler must answer 2xx quickly for the same reason.
• Recovery. If your SMPP client is disconnected, receipts wait for the next bind or may expire in the provider's queue. On REST, a provider may offer a re-push of receipts for a date range. Ask how each works.

Read more on what each status means in message delivery statuses explained.

How is encoding handled?

Both interfaces must choose between GSM-7 and Unicode, and both split long messages into segments. The difference is who does the work.

• REST: you set a field such as messageType to TEXT or UNICODE, and the platform segments long messages. Our API also has POST /sms/identify to count characters and segments first.
• SMPP: you set data_coding (0 for the GSM-7 default alphabet, 8 for UCS-2) and encode the bytes yourself. For long messages, you either add a User Data Header to each part and set esm_class to 0x40, or send the whole text in the message_payload field if your provider enables it.

Under 3GPP TS 23.040, a single SMS carries 140 octets: 160 GSM-7 characters or 70 UCS-2 characters, falling to 153 or 67 per part when the header is added. One Arabic letter or emoji makes the whole message Unicode. Encoding bugs are the most common SMPP integration fault, so test with Arabic, emoji and long texts. See our character limits guide.

How do security models compare?

REST relies on TLS and a bearer token per request. SMPP v3.4 has no encryption of its own and sends credentials in the bind, so it depends on the transport and network controls around it.

For SMPP:

• Use TLS (TLS 1.3 is defined in RFC 8446) or a private link; never plain SMPP over the public internet.
• Register source IP addresses so only your servers can bind.
• Store system_id and password as secrets, separate per environment, and rotate them if exposed.
• Monitor bind failures, which can signal misconfiguration or credential misuse.

For REST:

• Keep the token on servers only, never in mobile apps or browser code.
• Avoid legacy HTTP interfaces that pass a username and password in the URL, where they end up in logs.
• Protect the webhook with HTTPS, an unguessable path and strict body validation.

What does each option cost you to operate?

REST adds almost no operational burden: requests either succeed or return an error you can retry. SMPP adds a long-running component you must monitor and maintain.

An SMPP client needs:

1. connection management, with reconnection using backoff and jitter rather than a tight loop;
2. keep-alives and detection of silent, half-open connections;
3. window and rate control per bind;
4. sequence tracking and reconciliation after disconnects;
5. receipt acknowledgement and storage;
6. encoding and concatenation logic;
7. monitoring of bind state, throughput, throttling errors and receipt lag.

Mature open-source libraries handle the protocol, but your team still owns the behaviour around them, including during a provider maintenance window at 3 a.m.

When should you use each?

Use REST unless you have a clear reason to add SMPP.

Choose a REST SMS API when

• you send OTPs, alerts, notifications or campaigns from applications;
• you need WhatsApp, RCS or other channels as well as SMS;
• your platform runs on serverless functions or short-lived containers;
• your team has no SMPP experience and no need to build it.

Choose SMPP when

• you send high, sustained SMS volume and have reached REST limits;
• you already run an SMPP gateway or messaging platform;
• you are an aggregator, carrier or reseller connecting your own customers' SMS traffic;
• you need the same protocol across several upstream providers.

What does a hybrid setup look like?

Many businesses use both on one account: REST for multichannel and application traffic, SMPP for bulk SMS. The trap is ending up with two delivery models.

• Route by use case, not at random: for example, OTP and WhatsApp over REST, bulk SMS statements over SMPP.
• Normalise statuses from webhooks and deliver_sm into one table keyed by message ID.
• Use one sender ID policy across both, since registrations apply whichever interface you use.
• Report together, so a campaign split across both interfaces shows one result.

How do you migrate from an SMS API to SMPP?

Move gradually, with both interfaces running, and measure before you shift volume.

1. Confirm the need: document the volume or throughput that REST does not meet.
2. Request provisioning: share destination countries, sender IDs, expected peak throughput and source IP addresses.
3. Pick a mature client library in your stack and wrap it in your own send interface.
4. Build receipt handling first, mapped to the same status model as your webhooks.
5. Test encoding: GSM-7, Arabic, emoji and multi-part messages on real handsets.
6. Test failure: kill the connection mid-send, trigger throttling and check reconciliation.
7. Run in parallel: move a small share of one traffic type to SMPP and compare delivery and receipts.
8. Shift volume in steps, keeping REST as a fallback path.

An illustrative bind configuration looks like this. Host, port and limits are placeholders; real values come with your provisioned credentials.

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (empty unless told otherwise)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (alphanumeric sender ID)
dest_addr_ton/npi:    1 / 1   (international number)
registered_delivery:  1       (request delivery receipts)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

Worked example: a regional retailer adds SMPP for statements

"Souq Rafiq" (synthetic), an online retailer in the UAE, Egypt and Jordan, sends OTPs and order updates over a REST API and WhatsApp templates through the same API. Monthly account statements, sent by SMS to its whole customer base, have grown to the point where the REST job takes longer than the business wants.

• Decision: keep OTP, order updates and WhatsApp on REST. Move monthly statement SMS to an SMPP transceiver bind.
• Provisioning: the team registers two source IPs, confirms sender IDs per country and agrees throughput and number of binds.
• Build: a small SMPP service uses an open-source library, writes receipts into the same status table the webhook uses, and exposes the same internal send interface as the REST path.
• Testing: Arabic statements are confirmed as UCS-2 with correct concatenation on several handsets.
• Rollout: one country moves first. After comparing delivery and receipt timing with the REST baseline, the other countries follow, with REST kept as fallback.

Common mistakes

• Choosing SMPP for prestige. If REST meets your volume, SMPP only adds work.
• Running a window of 1, then blaming the provider for low throughput.
• Not acknowledging deliver_sm, which causes re-sent receipts and throttling.
• Reconnecting in a tight loop after a disconnect, which can look like an attack.
• Mixing short_message and message_payload in one PDU, causing length errors.
• Plain SMPP over the internet, exposing credentials and content.
• Two status models in a hybrid setup, so reports disagree.
• Limits: this guide describes common practice. Window sizes, rates, TLS ports and receipt details vary by provider and account; confirm them during provisioning.

How OmniChannels.ai helps

OmniChannels.ai offers both. The REST API at https://api.broadnet.me uses a Bearer token and covers SMS alongside WhatsApp, RCS, Messenger, Instagram, Telegram, Email and Push, with delivery statuses pushed to your webhook in one format. For high-volume SMS, SMPP 3.4 binds over TLS are provisioned per account, with allow-listed source IPs, and use the same SMS routes over BroadNet's direct operator connectivity. Resellers and wholesale partners can have dedicated binds. Start with the SMPP documentation or the quickstart, or see the developer overview.