You send SMS over HTTP API and 50k/day is smooth. Business hits 2M/day and you start dropping submits, latency spikes. The vendor says 'move to SMPP'. At what volume should you?
The two paths are fundamentally different
- HTTP API: connect-submit-close per request; simple but each has handshake overhead, ~50-200 TPS per connection.
- SMPP: persistent TCP, batched submit, 1000-3000 TPS per connection, built for concurrency.
A clear switching threshold
- < 100k/day: HTTP API is enough, low friction.
- 100k-500k/day: HTTP starts straining, plan the migration.
- > 500k/day or peak > 500 TPS: go SMPP, or submits queue and latency runs away.
Two SMPP params to get right
- Window size: how many submits you can stack before awaiting ack; 1 is too slow, 100+ congests, start at 10-30 and tune.
- Throttling: carriers cap submits/sec and reject extras, so smooth it with a client-side token bucket.
SMPP isn't 'more advanced' — it's 'handles more volume'. Below the threshold it's just more hassle.
FAQ
What is cross-border SMS and how does it differ from domestic SMS?
Cross-border SMS is sent via foreign carriers (Vietnam, Thailand, Indonesia…) to users worldwide; it differs from domestic SMS in routes, Sender ID, and per-country compliance.
Why is my SMS template rejected and how to fix it?
Usually sensitive words, wrong format, or unregistered Sender ID. Fix: use neutral wording, follow each country's template rules, register the brandname in advance.
Should I choose Brandname, OTP, or P2P SMS?
Brandname for branded marketing/notifications; OTP for verification codes; P2P for 1-to-1 chat. Choose by use case and delivery rate.
How are delivery rate (DLR) and pricing calculated?
Billed on DLR-confirmed successful sends; failed submissions are free. Look at actual delivery rate, not just submit volume.