Public shared numbers are a great QA tool and a poor CI tool. That distinction is most of the game, and most flaky SMS builds trace back to getting it wrong. Here's where public numbers earn their keep, where a provider sandbox belongs, and how to build an OTP flow worth testing.
Two jobs hiding under one word
"Testing OTP" sounds like one task. It's two, and they pull in opposite directions.
Automated CI wants determinism. It should never lean on a real, shared, rotating number. Manual and exploratory testing wants the opposite: realism, and a live public number in the country you need is handy there.
Pick the wrong tool and you've bought a failure nobody can reproduce on a Tuesday.
What public numbers are actually good at
A public number is at its best when a human is watching the screen.
Cross-country verification is the obvious win. Does your flow accept and parse codes from different regions, senders, and formats? Open a few countries and push the same flow through each.
Reproducing a bug report is the underrated one. A user abroad says verification is broken. Rather than provisioning a SIM or filing it under "can't reproduce," grab a number in their region and watch it fail yourself in minutes.
Then there's how senders format codes. "Your code is 123456." "G-123456." Digits with spaces between them. Real inboxes show you the variety your extraction logic must survive, which is why SMSS lists numbers by country.
Keep them out of your CI pipeline
Do not hardcode a public number into an automated suite. Three things will bite you.
Rotation. Public numbers appear and disappear. A number that's green today can be retired tomorrow, and now your pipeline is red for a reason unrelated to your code.
Sharing. The inbox is public. Another tester, or a stranger on the far side of the planet, can trigger or read a code at the same moment yours lands. Collisions, false failures, an afternoon lost to debugging something that was never broken.
Non-determinism. Real delivery carries latency and the occasional silent drop, precisely what a unit or integration test does not want.
For anything that runs on a schedule, use the sandbox.
Sandbox credentials, plus a handful of real sends
Twilio and most other SMS platforms ship magic test numbers and test credentials that simulate sends and deliveries for free, with no real traffic. Lean on these for the bulk of your suite. Assert that requesting a code hits the right API, that your rate limits fire, that expiry works, and that a wrong code gets rejected.
Then keep a small set of real-route smoke tests that confirm an actual SMS reaches an actual handset. Run those now and then, not on every commit. Fast deterministic checks underneath, a periodic reality check on top.
Respect the same limits your users hit
Whatever you're testing against, don't hammer it. Requesting codes in a tight loop trips provider and platform rate limits and can get a number temporarily blocked, the same machinery behind SMS pumping defenses. Add backoff. Cap resends. Test that your own UI handles a "too many requests" response without falling over.
The UX is part of the test
While you're in the flow, check that it feels right and not just that it works:
- A resend button that's on a timer, not permanently live.
- SMS one-time-code autofill wherever the platform supports it.
- Error copy that says something ("that code expired") instead of shrugging ("something went wrong").
- A code input that's properly labeled and works with autofill and screen readers.
- Sensible expiry and single-use enforcement, the way OTP codes are meant to work.
None of this shows up in a passing green check. All of it shows up in your support queue.
Where each tool lands
Sandbox credentials carry your automation. A few real-route smoke tests keep you honest. And public numbers handle the manual, cross-country exploration they're genuinely good at. Keep shared numbers out of CI, throttle your requests, and test the parts of the experience a passing build never touches. Get that mix right and your OTP flow survives both the pipeline and someone's actual phone.
Frequently asked questions
Can I use public numbers in automated tests?
Not reliably. Public numbers rotate and are shared, so hardcoding one into CI will eventually break the build and can leak or collide with other testers. Use provider test credentials for automation and save public numbers for manual, exploratory QA.
How do I test OTP without paying for real SMS?
Most SMS providers offer magic test numbers and sandbox credentials that simulate delivery for free. Use those for functional and CI tests, and reserve real-route sends for occasional end-to-end smoke checks.
What are test phone numbers?
They are provider-supplied numbers (or codes) that behave predictably in a sandbox. They "receive" a code without sending a real SMS, so you can assert on your flow without cost or flakiness.
When are public shared numbers actually useful for developers?
For manual cross-country checks (confirming your verification works with different regions, senders, and formats), and for quickly reproducing a user report without provisioning a SIM.
Try it yourself
Receive an SMS code on a free public number in seconds — no sign-up required.