Skip to main content
If your app signs users in by phone number, Mini needs two things from you: a number it can type, and a code it can type next. You put both on the profile, and you make them work by configuring your own staging backend. Mini does not own a phone number and cannot read SMS. That’s a deliberate choice, not a gap we forgot about. Buying and pooling real numbers means running a phone-number vendor, keeping the pool clean across every customer, and handling carrier delivery failures inside a test run. Your staging backend already has a way to bypass all of that.

​
What you configure

1

Pick a test number

Any number you control the behaviour of in staging. It never receives a real SMS, so it doesn’t need to be a number you own with a carrier.
2

Whitelist it in your staging backend

Make your OTP endpoint accept that number without sending anything, and accept one fixed code for it. Most teams already have this for their own manual QA.
3

Put both on the profile

In App settings → Test accounts, open the profile, turn on Phone login and fill Phone number (international format, +33612345678) and Static OTP code (the fixed code you pinned).
At runtime Mini types the number on the sign-in screen, waits for the code screen, and types the code. Nothing else changes about how the story runs.
The static code is stored encrypted and masked in the dashboard, same as a password. It’s never echoed in run reports, Slack messages, or fix prompts.

​
The generic case

The shape of the change is the same whatever your stack: when the request is for a whitelisted test number, skip the send and accept a known code.
Two things worth getting right:
  • Staging only. Gate the list behind an environment flag so a whitelisted number can never be used against production data.
  • One code per number. Don’t accept “any code” for a test number. If verification stops asserting anything, your login story stops testing login.

​
If you’re on Twilio Verify

There’s no shortcut here: Twilio ships no test mode for Verify. Its test credentials only cover phone numbers, calls, and messages. A Verify request made with them comes back 403. The magic numbers you may have seen (+15005550006 and friends) are fixtures for the Messages API, not Verify recipients. So the allowlist above is still the answer, you just put it one step earlier: short-circuit before you call Verify, in both your request and your check handler. Your production path stays exactly as it is.

​
If you can’t configure it

Tell us. It changes what we build next. Until then, a story that needs a phone-OTP login and has no configured number and code doesn’t fail with a mystery. Mini skips it and the run report names the missing configuration, so you can tell “the app is broken” apart from “the test account isn’t set up”. Other stories in the run are unaffected. The obvious alternative is a pool of Minitap-owned numbers Mini can read SMS from. We’ve deliberately not built it: it makes us a phone-number vendor, adds carrier delivery as a failure mode inside every run, and still wouldn’t work for apps that pin an account to a number. If your app can’t whitelist a test number, say so and we’ll look at it again with your case in hand.