OTP routing is the decision layer that chooses which number, supplier path and region will receive a verification code for a given request. When volume is low, a single path is good enough. Once you handle thousands of requests per hour, the routing choice becomes the biggest single lever on success rate, latency and cost.
What a routing decision actually includes
Every request carries a few inputs: the target service, the country, the price ceiling and the user's urgency. A router turns those inputs into one concrete choice. That choice is rarely just a phone number. It usually bundles the number pool, the upstream supplier, and sometimes a preferred time window.
- Service and country narrow the candidate pool to numbers that have worked for that exact pairing.
- Recent outcomes weigh candidates by how often codes actually arrived in the last hour or day.
- Cost breaks ties when two paths perform about the same.
- Capacity removes paths that are nearly out of stock.
Static rules versus scored routing
Static routing is a lookup table: service A in country B goes to supplier C. It is easy to audit and easy to explain to support staff. Its weakness is staleness. A supplier that was excellent last month may be degraded today, and a table will not notice.
Scored routing assigns every candidate a number between zero and one built from recent success rate, median delivery time and error frequency. The router picks the highest score, usually with a small random exploration share so that recovering paths get a chance to prove themselves again.
Designing the fallback chain
A fallback chain should be short and ordered. Three levels are plenty for most systems: the preferred path, a proven alternate, and a last resort that accepts a higher price. Each step needs a clear trigger so you do not bounce a request across five suppliers.
- Try the primary path once and wait for the code window defined for that service.
- If the window closes with no code, release the number and cancel the order so the customer is not charged.
- Retry on the alternate path only when the customer has opted into an automatic retry.
- Record every hop in the order history so you can analyse it later.
Sticky routing and why it helps
Some flows send a code, then ask the user to request another one. If the second request lands on a different path, delivery time and sender reputation can change midway. Sticky routing keeps the same path for the same order, which makes behaviour consistent and debugging far simpler.
Rolling out routing changes safely
Treat a routing change like a code deploy. Shift a small percentage of traffic to the new rule, compare success rate and median time to code against the control group, and expand only when the numbers hold. Always keep a one step rollback that restores the previous table.
route = score(candidates, window='60m')
choice = pick(route, explore=0.05)
if choice.capacity < 3:
choice = next_best(route)Finally, publish routing decisions to your logs in a structured form: service, country, path, score at decision time and final outcome. Without that record, nobody can tell whether a drop in success was caused by routing or by an upstream outage.
Frequently asked questions
How much traffic should go to exploration paths?
Keep exploration small, around three to five percent. That is enough to refresh scores for recovering paths without exposing many users to an unproven route. Raise it temporarily after an outage, then lower it again once scores stabilise.
Should routing differ by time of day?
Sometimes. If delay or success changes by local hour, add the hour as a routing input or at least as a reporting segment. Do this only when you have enough volume, otherwise the pattern is just noise and the extra rules add complexity without benefit.
Who should own routing rules?
Give one team clear ownership, and require review for changes. Routing affects revenue, cost and support load at once, so changes need a short written reason, a rollout plan and a named person to watch the metrics afterwards.
Keep going
Check the services list for current availability, then use the API docs to wire the flow into your own product. If you want background on the platform, visit the about page. Answers to everyday questions live in the help center, and the contact page reaches a person. More articles are on the blog. To place an order, log in to the verification dashboard.
Related reading: Routing Health Scores and Failover for SMS Verification and Monitoring SMS Verification Success Rate Dashboards.
