SMPP vs HTTP API: Which Connection Should You Use for A2P SMS?

This question gets answered badly in both directions: platforms build an SMPP integration they did not need, or they push serious volume through an HTTP API and then wonder why their throughput plateaus. The routes are identical. The difference is in how your platform wants to talk.

What SMPP is good at

SMPP is a binary protocol over a persistent TCP session, designed for exactly this job. That gives it three advantages at volume:

• Low per-message overhead. No TLS handshake, no HTTP headers, no connection setup per message. At high sustained rates this is the difference between comfortable and expensive.
• Receipts on the same session. Delivery receipts return down the connection you already have open, rather than requiring you to expose and maintain a public webhook endpoint.
• Predictable throughput. Throughput is negotiated per bind, so you know what you have rather than discovering a rate limit in production.

The cost is operational: a persistent session needs reconnection logic, enquire_link keepalives, window management and sequence-number handling. That is a day of work for someone who has done it before and a fortnight for someone who has not.

What an HTTP API is good at

An HTTPS JSON API is stateless, familiar to every developer on your team, and debuggable with tools you already have. Its advantages:

• Time to first message. Minutes, not an interop call.
• Fits request-response architectures. If your platform is a set of serverless functions, holding a persistent TCP session is awkward at best.
• Trivially observable. Every request is a log line your existing tooling already understands.

The costs are per-message overhead at high rates, and the need to expose a webhook endpoint for delivery receipts, which then has to stay available, or you lose receipts you cannot recover.

How to choose

A rough rule that holds up in practice:

• Sustained high throughput, dedicated infrastructure, a team that has done SMPP before: use SMPP.
• Moderate or bursty volume, serverless or containerised architecture, speed to launch matters: use the HTTP API.
• Not sure: start on the API and move to SMPP when throughput becomes a real constraint rather than a theoretical one. On our platform that migration does not change your routes, your rates or your balance.

Things people get wrong

Assuming SMPP is faster end to end. It has lower per-message overhead, which matters at rate. It does not make an individual message arrive sooner, that is the route, not the protocol.

Opening one bind and expecting unlimited throughput. Throughput is per bind and agreed with your provider. If you need more, you ask for more binds or a higher rate, in advance.

Treating the webhook as fire-and-forget. If your receipt endpoint is down, receipts queue and then expire. Return 200 fast, process asynchronously, and monitor the endpoint like production infrastructure, because it is.

Ignoring encoding. A single non-GSM character silently switches the whole message to UCS-2 and cuts your segment length from 160 characters to 70. Test your actual message templates, in every language you send.

Using both

There is no reason to pick one forever. On a single SisBird account you can run SMPP for your high-volume transactional stream and the HTTP API for a lower-volume service that sits elsewhere in your estate, against one balance and one set of reports.