SimSmsBox When an SMS verification code doesn’t show up, the platform is rarely broken — you’ve usually hit one of a few common cases: the range is risk-flagged by the target, the service had no stock at that moment, you polled too early, or the target simply won’t deliver to virtual numbers. Work through the order below and you’ll locate it in minutes.
First: “not sent” vs “not fetched”
These are two different problems with different fixes.
- Not sent: the carrier or target platform never delivered the SMS to this number.
- Not fetched: the SMS actually arrived, but your polling was off (fetched too early, timeout too short).
Check the order’s status in the dashboard first, then decide — don’t refund and swap numbers on reflex.
8 common causes and their fixes
| Cause | Typical symptom | Fix |
|---|---|---|
| Range risk-flagged | Stuck “waiting”, times out and refunds | Swap and retry; for the long run prefer real SIM, see Real SIM vs virtual numbers |
| No stock for that service | Order fails or refunds instantly | Switch platform or country; check stock stability first, see How to choose an SMS platform |
| Polled too early | Empty polling right after ordering | Wait 10–30s before polling, see Automated polling |
| Target blocks virtual numbers | ”This number can’t receive SMS” | Use a real SIM, or another receiving method |
| Secondary risk control triggered | First code arrives, later ones don’t | Lower the reuse frequency of the same number |
| Country mismatch | Signup region doesn’t support that range | Pick a country the target clearly supports |
| SMS delayed or merged | Arrives minutes later | Extend the wait a bit, don’t call failure too soon |
| Poll timeout too short | Judged failed before delivery | Increase the timeout, see the example below |
Don’t burn balance on empty polling
Plenty of “not received” cases are just sloppy polling: order, hammer the query, call it failed and refund within seconds. The right way is to wait a moment, then poll on a fixed interval with an overall timeout:
# 1) Order a number (service = the service code from market, e.g. telegram; country = US)
curl -X POST https://api.simsmsbox.com/api/sms/orders/purchase \
-H "X-API-Key: psk_xxx" \
-H "Content-Type: application/json" \
-d '{"service":"telegram","country":"US","cardKind":"physical","rentDays":30}'
# -> { "orderId": 19, "phone": "+1xxxxxxxxxx", ... }
# 2) Wait 15s, then query every 5s for up to 2 minutes; {id} = the orderId above
sleep 15
for i in $(seq 1 24); do
resp=$(curl -s https://api.simsmsbox.com/api/sms/orders/19 -H "X-API-Key: psk_xxx")
echo "$resp" | grep -q '"latestCode":"' && { echo "$resp"; break; }
sleep 5
doneFor cadence and retry strategy, see the Automated polling tutorial.
Still nothing? Swapping beats waiting
If a number sits through the full timeout with no delivery, the number is probably flagged by the target — waiting longer is wasted time. Cancel and swap; it’s far more efficient than grinding one number. The rule is simple: don’t reuse a number that timed out and refunded.
Wrap-up
Separate “not sent” from “not fetched” first, then decide between swapping numbers and fixing your polling; for long-term stability the source of the number matters more than its unit price. Further reading: How to lower your SMS failure rate.