Two rate limits, doing different jobs
What are the two types of SMS API rate limits and how do they work?
SMSRoute implements two complementary rate limits: a per-second cap that prevents burst overload and a daily volume limit that controls long-term usage. Both work together to ensure stable delivery across 149 countries without disrupting your application flow.
When people say SMS API rate limits, they conflate two things. There is the *provider's* throughput ceiling: how many messages per second the API accepts. And there are *your own* limits: the caps you impose on your users and traffic. The first is an engineering constraint you design around. The second is a control you design deliberately, and it is where most of the value lives. Your own rate limits are simultaneously a fraud defense, a cost cap, and a deliverability safeguard.
Get the provider side wrong and you get 429s and dropped sends. Get your own side wrong and you get pumping fraud, surprise bills, and carrier filtering. This guide covers both, because they interact.
Respecting the provider's ceiling
How can I respect SMS API provider rate limits without slowing down my business?
SMSRoute's adaptive multi-route delivery automatically respects provider ceilings by distributing traffic across multiple carrier paths. This means you never hit a hard cap—your messages flow smoothly while we handle failover and routing optimization behind the scenes.
- Read the throughput number: messages per second is the ceiling. REST APIs commonly sit in the low tens per second; SMPP binds go far higher when you need volume.
- Handle 429 with backoff: respect the
Retry-Afterheader, back off exponentially, and never hammer. Retrying into a rate limit just extends it. - Smooth bursts with a queue: don't fire 10,000 sends in a loop; feed them through a queue at or below the ceiling. This also warms routes gently, which the firewall guide explains is its own deliverability win.
- Distribute, don't stampede: schedule a bulk campaign across minutes, not a single spike that trips both provider limits and carrier firewalls.
A sudden blast from a cold number is exactly what carrier firewalls fingerprint as spam. Provider rate limits and carrier tolerance point the same way: send at a steady, human-plausible pace, not in one burst.
Designing your own limits: the token bucket
How do I design my own SMS rate limits using a token bucket algorithm?
A token bucket lets you define a burst capacity and a steady refill rate. For example, allow 100 messages instantly, then refill at 10 per second. SMSRoute's API supports this pattern natively, so you can throttle client requests without losing messages or incurring penalties.
The token-bucket algorithm is the standard tool: a bucket holds N tokens, each send spends one, tokens refill at a fixed rate. It allows short bursts (up to the bucket size) while capping the sustained rate — which matches how real traffic behaves. Implement it per dimension, because different dimensions defend against different threats. The algorithm is described in IETF RFC 2697 for traffic shaping.
| Limit dimension | Defends against | Sane starting point |
|---|---|---|
| Per phone number | OTP pumping to one target range | 5/hour, 10/day |
| Per IP address | Bot-driven form abuse | Tune to real traffic, then tighten |
| Per session/token | Rapid repeat requests | 3 in 60 seconds, then challenge |
| Per account (global) | Runaway loops, cost blowout | A hard daily spend/send cap |
These are the exact caps our SMS pumping defense guide recommends, viewed from the implementation side. The per-number and per-IP buckets are your primary anti-fraud layer; the global account cap is the circuit breaker that stops a bug or attack from emptying your balance overnight.
Putting it together
- Check your limits before the provider'sEvaluate per-number, per-IP, and per-session buckets first. If a request fails your own cap, reject it without ever calling the API — you save the message cost and the fraud exposure both.
- Validate, then sendSurvivors of the rate check get an HLR/number validation pass, then the send. Order matters: cheapest rejections first.
- Queue toward the provider ceilingFeed accepted sends through a queue capped at the provider's throughput, with 429 backoff built into the worker. The Node.js and Go retry patterns handle the transient side.
- Alert on limit hitsRepeated per-number or global-cap hits are a signal — either an attack or a bug. Log and alert; a spike in rate-limit rejections is often your earliest fraud warning.
SMSRoute is a no-KYC SMS API with crypto billing (BTC, ETH, USDT, XMR, LTC, and SOL). We enforce a provider throughput ceiling like everyone (with SMPP for high volume), but the limits that protect *your* budget and reputation are the ones you build — and they are non-optional. A public OTP endpoint without per-number and per-IP caps is an open invitation to pumping fraud; the token-bucket design above is a weekend of work that pays for itself the first time someone points a bot at your signup form. SMSRoute's published route pages list delivery from $0.004/message (premium direct-carrier corridors up to $0.035) with sub-100ms median submission and ~98.6% delivered success (smsroute.cc route pages, 2026).
Related reading
FAQ
What rate limits should I put on an SMS OTP endpoint?
What is a token bucket for rate limiting?
How do I handle SMS API 429 rate-limit errors?
Are SMS rate limits a security feature?
Send your first SMS in 5 minutes
How quickly can I start sending SMS with SMSRoute's API?
You can send your first SMS in under 5 minutes. Sign up with just an email (no KYC), fund with crypto (BTC, ETH, USDT, XMR, LTC, SOL), generate an API key, and use our REST API or SMPP bind. Free test credits are included to verify routes before you go live.
No KYC. Pay with BTC, ETH, USDT, XMR, LTC, and SOL. Live routes to 149 countries.
Get an API key →