Twilio now blocks new Toll-Free messaging verifications without public privacy and terms URLs

Twilio made Privacy Policy and Terms and Conditions URLs mandatory inputs for new Toll-Free Verification submissions effective September 15, 2026. Twilio’s onboarding guidance says both URLs must be publicly accessible, relevant to the business being verified and consistent with the policies shown to consumers at the messaging opt-in point. Missing, unreachable or inadequate URLs can trigger rejection such as error 30493. A Toll-Free number that is not approved cannot send messaging traffic to the United States and Canada. Twilio also introduced more specific rejection codes under a unified content and messaging policy shared across Toll-Free Verification and A2P 10DLC, making failed registrations more machine-actionable.

For messaging products, verification is part of the production delivery path. An onboarding flow that submits a number before the customer has publishable policy pages can now fail even when the rest of the business and messaging data is valid. ISVs and SaaS products that create Toll-Free verifications through Twilio’s API therefore need a new prerequisite and validation step. The change also shifts privacy/terms compliance from prose buried in a messaging description into explicit URLs that Twilio can retrieve and compare with the user-facing opt-in flow.

Teams can no longer assume they can complete Toll-Free verification first and tidy legal links later. The required policy URLs need to exist, be reachable without authentication and be suitable for the business/use case at submission time.

Twilio says the Privacy Policy and Terms of Service supplied in verification should match the versions presented to consumers at the call-to-action. This matters for platforms that generate generic account-level legal pages while the embedded customer’s opt-in flow points somewhere different.

Twilio states that Toll-Free numbers cannot send messaging traffic to the US and Canada until verification is approved. A registration rejection can therefore delay launch or break an onboarding promise, not just create a compliance ticket.

Builders using Twilio’s verification API should capture the two URLs before submission, check they return successful public responses and ensure the content is not placeholder or under construction. A syntactically valid URL can still fail vetting if it does not contain the expected policy content.

Twilio’s September 15 policy update also makes rejection feedback more granular across Toll-Free and A2P 10DLC. Platforms can map individual rejection reasons to customer-facing remediation steps rather than collapsing failures into a generic 'verification rejected' state.