Twilio Verify for Signup 2FA: SMS Fallback, TTL, and Rate Limit Guardrails

A signup flow that stops at the SMS

A new user reaches your registration page, enters a mobile number, and waits for a one-time password (OTP). The SMS never arrives. Maybe the carrier filtered it, the number is a landline, or the user is traveling outside your primary region. If your verification code only attempts SMS and then fails, that user abandons the account before they ever see your product.

Twilio Verify is a managed API that sends OTPs over SMS, voice, or push and validates the user's reply automatically. You do not generate or store the codes yourself; Twilio handles expiration and comparison through its Verify service.

Configure fallback and OTP lifetime before you send

In the Twilio Console, create a Verify service and note its Service SID. Under delivery settings, enable SMS as the primary channel and voice as fallback. When an SMS cannot reach the handset, Twilio can place an automated call that reads the code aloud. This catches landlines and some carrier filtering without requiring a second integration.

Set the time-to-live (TTL), which is how long the code remains valid. The default is five minutes. A shorter TTL reduces the window for phishing or code reuse, but it also increases frustration if network delay pushes delivery close to the limit. For a signup flow, five minutes is usually a reasonable starting point.

Worked example: send and check an OTP

Run these commands from a terminal or local development machine. You need a Twilio Account SID, Auth Token, and Verify Service SID. Replace the placeholders with your own values. Sending a verification incurs Twilio usage charges, so use a number you own for testing.

# Send an OTP via SMS, with voice fallback configured on the service
curl -X POST "https://verify.twilio.com/v2/Services/$VERIFY_SERVICE_SID/Verifications" \
  --data-urlencode "To=+15550001234" \
  --data-urlencode "Channel=sms" \
  -u "$ACCOUNT_SID:$AUTH_TOKEN"

Expected check: an HTTP 201 response with a verification SID and status pending. If the number is unreachable by SMS and voice fallback is enabled, Twilio attempts the call automatically.

# Validate the code the user submits
curl -X POST "https://verify.twilio.com/v2/Services/$VERIFY_SERVICE_SID/VerificationCheck" \
  --data-urlencode "To=+15550001234" \
  --data-urlencode "Code=123456" \
  -u "$ACCOUNT_SID:$AUTH_TOKEN"

Expected check: HTTP 200 with status approved if the code matches and has not expired, or pending if it is still awaiting input. A wrong or expired code returns an error status rather than approval.

Risk: every verification attempt costs money. Do not loop this request in tests against real phone numbers, and validate input on the client so malformed numbers do not generate billable messages.

Rate limits and cost are the real constraints

Twilio enforces rate limits per account. If your signup flow bursts past them, the API returns HTTP 429 and temporarily throttles further requests. That can block legitimate users during a marketing campaign or a bot-driven signup spike. Handle 429 with exponential backoff, or queue verification requests so a slow backend does not fail the whole page.

Cost is per message. SMS prices vary by destination country, and voice fallback is billed per minute. International signup can become expensive quickly if you do not restrict target regions or monitor usage. Before enabling verification for a new country, check Twilio's pricing page for that region and compare it against your expected conversion rate.

Limitations: Twilio Verify does not let you customize the OTP generation algorithm or the message template beyond the provided options. Messages carry Twilio's default format, so you cannot inject brand language. The optional trusted device feature reduces repeat authentication but requires storing a device identifier on the client, which introduces privacy considerations you should document.

Verify it works before you launch

1. Send a test OTP to your own phone number from a staging environment.
2. Confirm the SMS arrives, and confirm that a landline receives the voice call if SMS fails.
3. Enter the code in your application and confirm the Verify check returns approved.
4. Open the Twilio Console usage dashboard and confirm the message appears with the expected price for your region.

If the test passes, enable voice fallback, keep the TTL at five minutes, add 429 handling to your signup endpoint, and restrict unverified regions until you have priced them.

Bottom line

Use Twilio Verify to offload OTP generation and validation, but do not treat SMS as guaranteed delivery. Configure voice fallback, choose a TTL that balances security and friction, and treat rate limits and international pricing as part of your onboarding design, not an afterthought.