Ninja Mountain symbolNinjaMountain

T013

Verify API: sending OTP but users never receive the code

Ticket

We integrated the Twilio Verify API to send OTP codes for user login. The API returns a 'pending' status when we create the verification, which we understand means it was accepted, but a significant portion of our users (we estimate 20-30%) report never receiving the SMS. We are NOT using a custom template. This seems to affect users on certain carriers more than others - we've noticed AT&T users have more complaints. Our Verify Service SID is VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Is there a deliverability issue with Verify specifically or could this be a 10DLC registration problem?

Gold label: bug / high

Results by run

openai · gpt-5.5

2026-10-04 17:23 UTC · prompt ef0017a

config (wrong)
high (correct)
escalate: no

Summary

A significant share of users are not receiving Verify SMS OTPs even though verification creation returns pending, with complaints concentrated on certain carriers such as AT&T.

Suggested first response

Thanks for the details. A `pending` Verify status means the verification was created, but it does not by itself confirm handset delivery. Please send a few affected phone numbers, timestamps, and any Verification SIDs or related Message SIDs so we can review the Verify and Messaging logs for carrier delivery results, filtering codes, rate limits, invalid/unsupported recipient types, or opt-out blocks. We should also verify your Service configuration and sender/A2P 10DLC setup for US SMS traffic, especially since the issue appears carrier-specific.

KB citations

kb-010, kb-004

608 output tokens · 8.1s · 1 attempt(s)

anthropic · claude-sonnet-4-6

2026-10-04 17:20 UTC · prompt ef0017a

bug (correct)
high (correct)
escalate: yes

Summary

20-30% of users on certain carriers (notably AT&T) are not receiving Verify OTP SMS codes despite the API returning a 'pending' status.

Suggested first response

Thank you for reaching out and for the detailed information. A 'pending' status from the Verify API confirms Twilio accepted the verification request, but it does not guarantee downstream carrier delivery — so the issue is likely occurring between Twilio and the carrier. The carrier-specific pattern you're seeing (AT&T users disproportionately affected) is a strong signal of a deliverability or 10DLC registration issue. Here are the steps we'd like you to take immediately: 1. **Check your Verify logs in the Console Debugger** for your Service SID (VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx). Look for any error codes on the affected verifications — particularly 60205 (landline), 60207 (rate limit), or 60203 (max send attempts reached). 2. **Confirm your 10DLC campaign registration status.** AT&T is known to enforce A2P 10DLC filtering strictly. If your campaign is unregistered, pending, or was rejected, AT&T traffic is very likely being filtered (carrier error 30007). Please share your Brand and Campaign registration status so we can investigate further. 3. **Check for opt-out (STOP) records** — if any affected users previously opted out, Twilio will suppress delivery (error 21610). We are escalating this to our engineering and carrier operations team given the scale of impact (20-30% of users) and the carrier-specific pattern. Please reply with any error codes you find in the Verify logs and your 10DLC campaign registration details so we can expedite the investigation.

KB citations

kb-010, kb-004, kb-012

438 output tokens · 12.4s · 1 attempt(s)