Everything worth knowing, nothing that isn't.
Why it exists
Operators and platforms allocate finite throughput, so a provider meters submission to stay within route capacity and honour fair-use terms. Rate limiting also blunts SMS pumping, where fraudsters trigger floods of OTPs to earn a cut of the traffic. See /answers/what-is-sms-pumping and /answers/what-is-tps.
Where limits apply
Common dimensions are per API key (your account's overall submission rate), per sender ID or number, and per destination MSISDN (to stop repeated sends to one victim). Verification flows should cap OTP requests per number and per IP. See /answers/sms-otp-best-practices.
How to work with it
Design senders to respect HTTP 429 / SMPP throttling responses with exponential backoff, batch large campaigns within your allotted rate, and request a higher limit ahead of a known spike rather than hitting the ceiling live. See /answers/what-is-throughput-sla.
Rate limiting vs throttling
The terms overlap: rate limiting usually means a hard cap you must stay under, while throttling means the platform is actively slowing your traffic to a sustainable rate. Both protect delivery. See /answers/what-is-cps.