The toll-free verification maze
Twilio rejected the same toll-free application twice, for two different fields, before it explained why. The map of that maze, built one collision at a time.
A toll-free number needs Twilio's sign-off before it can send a single text. The application is one form — business details, opt-in method, use case. It reads like paperwork. It behaves like a maze: you can't see a wall until you've already walked into it, and the rejection notice is the only map you get.
01 First submission
The number was for one narrow job: an AI voice hotline sending a single follow-up text after a call, capped low, filed under customer-care use. First submission came back rejected — business details inaccurate. The field at fault was business_website. It pointed at a personal domain that redirects elsewhere, and the reviewer followed the redirect to a page that matched nothing else in the application. Nothing else in the form was wrong. One URL sank the whole submission.
02 Second submission
Fix the website field, resubmit, and the wall moves. Second rejection — opt-in doesn't reflect the actual business. The field this time was opt_in_type, set to WEB_FORM, as if there were a signup box somewhere collecting numbers. There isn't. The only way anyone ends up on this list is by calling the hotline and hearing a disclosure before anything gets sent — that's VERBAL, a different enum value entirely. Twilio's taxonomy doesn't treat "close enough" as valid. WEB_FORM and VERBAL aren't two names for the same consent; they're different mechanisms with different proof requirements attached.
03 A wall routed around blind
One more field got changed in that same pass, before it had the chance to reject anything on its own: business_type, set to SOLE_PROPRIETOR. Not because the business is legally structured that way in any deeper sense — because that value is the one that skips the business-registration-number and EIN fields, paperwork a one-person operation registered only with the city doesn't have. Reading the enum definitions before submitting instead of after is the one wall you can route around blind. Compressed into a single picture: three fields, each with a value that goes nowhere next to the value that doesn't. Nobody hands you this diagram going in. You build it out of rejection notices, one at a time.
04 Where it stands
The application can only be edited while its status is rejected and editing is still allowed — miss that window, or miss the seven-day clock that keeps a resubmission in the priority queue, and the next attempt gets treated as brand new, back of the line. This round, the status flipped to in-review faster than expected, before two free-text fields — additional information, use-case summary — could be updated. They still cite the old domain and the old consent page. Whether that triggers a third rejection isn't known yet. The only way to fix those two fields now is to wait for that rejection to arrive.
A maze doesn't publish its map. You learn each wall by walking into it, and you don't get to fix the last one until the next collision tells you it's still there.