OTP Polling vs Webhooks: How to Read Verification Codes in Your App
When you order a number through an API, the SMS does not arrive in the same response. Your code has to find out later that a message came in. There are two common patterns for this, polling and webhooks, and choosing the wrong one makes apps slow, fragile or rate limited.
Short answer: use polling when you only need a few codes and want the simplest code, and use webhooks when you handle many orders and want instant delivery without extra requests. Many OTP APIs, including simple REST ones, rely on polling, so build a polite polling loop first.
How polling works
Your server asks, again and again, whether the SMS has arrived. Each request returns a status such as waiting or received. You stop when you get a code, when the order is cancelled or when the time limit is reached.
How webhooks work
Instead of asking, you give the provider a URL. When the SMS arrives, the provider calls your URL once with the data. You need a public endpoint, a way to verify the call is genuine and a plan for retries if your server is down.
Comparison
| Polling | Webhooks | |
|---|---|---|
| Setup effort | Low | Higher |
| Speed | Depends on interval | Instant |
| Server load | More requests | Fewer requests |
| Needs public URL | No | Yes |
| Failure handling | Next poll fixes it | Needs retry logic |
A polite polling loop
- Order the number and store the order id.
- Wait two to three seconds before the first check.
- Poll every three to five seconds, not every 100 milliseconds.
- Stop after the order time limit and cancel the order.
- On an error response, back off before trying again.
- Never poll an order that is already finished or cancelled.
Mistakes to avoid
- Polling in a tight loop without a delay.
- Forgetting to stop polling after cancel.
- Parsing the code with a fragile pattern that breaks when the message text changes.
- Ignoring the balance after repeated failures.
Using the OtpGet API
The OtpGet API uses REST requests with one key, so a simple polling loop is the easiest way to start. Test with a small balance, log every response and add your own limits so a bug cannot burn through your balance.
Pseudo-code for a safe polling loop
order = create_order(service, country), then deadline = now + order_time_limit. While now < deadline: wait a few seconds, call the status endpoint, if a code is present save it and stop, if the status says cancelled stop, if an error occurs wait longer and continue. When the deadline passes, cancel the order and record the failure. This short pattern prevents the three most common bugs: endless loops, missing cancels and request storms.
Testing your integration
- Run one order by hand from the website and note the status names.
- Run the same flow from your code with a small balance.
- Simulate a timeout by cancelling the order and check your loop stops.
- Simulate an API error by using a wrong key and check your backoff works.
- Only then run ten orders in a row.
Frequently asked questions
What interval should I use?
Every three to five seconds is a good start. Shorter intervals add load without making codes arrive faster.
Do I need webhooks for a reseller site?
Not at first. Add them if polling cost becomes a problem.
How do I stop duplicate processing?
Store the order id and mark it finished the moment you read the code.
Related guides and pages
Create a free OtpGet account and test with a small balance first.