OTP API Rate Limits: How to Poll for Codes Without Being Throttled
An OTP integration that works in a test with one order can break with fifty at once. The usual cause is sending too many requests too fast, which makes the API answer with errors or block the key for a while. Here is how to keep your integration inside the limits.
Short answer: poll no more often than every few seconds, share one status call across many orders where the API allows it, back off after errors and never retry blindly. If the API tells you to slow down, believe it and wait.
Why APIs limit requests
Limits protect the service for everyone. If one client sends thousands of calls a minute, the others suffer. A limit is not a punishment, it is a contract: stay below it and the API stays responsive.
Signs that you are being throttled
- Responses with errors that mention too many requests.
- Sudden delays in answers.
- Orders that work from your laptop but fail from your server at busy times.
Good habits
- Use a delay between polls of at least a few seconds.
- Add a small random jitter so many workers do not fire at the same moment.
- Back off exponentially after an error: wait 2, 4, 8 seconds, up to a maximum.
- Cache the balance and price data instead of asking for them on every order.
- Use one worker queue instead of one thread per order.
Example of exponential backoff
First error, wait two seconds. Second error, wait four. Third error, wait eight. After a maximum such as sixty seconds, stop and log the failure for a person to look at. Always reset the wait after a successful call.
Protect your balance too
- Set a daily spending limit in your own code.
- Stop ordering if several orders in a row fail.
- Alert yourself when the balance falls under a threshold.
Where to start
Read the endpoint notes on the OTP API page, start with one order at a time and increase only when your logs look clean.
Designing for many users
If you run a bot or a reseller site, one slow customer can create many polls. Put all active orders into a single queue and let one worker check them in turns instead of letting every request page poll on its own. Add a global cap on requests per second and a per-user cap on active orders. These two caps protect both the provider and your own balance.
What to log
- Order id and service.
- Status and time of each check.
- Error type and the wait you applied.
- Never log keys, passwords or full phone numbers in public places.
Frequently asked questions
What happens if I ignore rate limits?
The key can be slowed or blocked for a time, and your orders will stall.
Is polling every second faster?
No. The SMS arrives when it arrives, so faster polling only adds load.
Should I log every request?
Log the order id, status and time, but never log your API key.
Related guides and pages
Create a free OtpGet account and test with a small balance first.