If your product sends SMS through Twilio in the United States, there's a Messaging Service campaign registered against your A2P 10DLC brand. On June 30, 2026, two new fields become required on every campaign registration: PrivacyPolicyUrl and TermsAndConditionsUrl. Submissions without them will return a hard 400 from Twilio.
This is the kind of change that doesn't break anything — until it does. Existing campaigns keep delivering messages. New campaigns and any update to a campaign hit the new validator the moment you touch it.
What's changing
Today, Twilio's A2P 10DLC campaign registration accepts campaigns without a privacy policy URL or terms-and-conditions URL on the campaign object itself. Brand-level URLs cover the carrier compliance story, and the campaign-level fields are technically optional.
After June 30, 2026:
-
PrivacyPolicyUrlis required on every new campaign registration -
TermsAndConditionsUrlis required on every new campaign registration - Both URLs must resolve to publicly reachable HTTPS pages — Twilio fetches them as part of the registration check
- The privacy policy must explicitly mention SMS data collection and that opt-in data is not shared with third parties
- Terms must include the program's purpose, opt-out instructions ("STOP"), and the help keyword behavior ("HELP")
Submitting a campaign without either field after the cutoff returns:
HTTP 400 Bad Request
{
"code": 21610,
"message": "PrivacyPolicyUrl is required for campaign registration",
"more_info": "https://www.twilio.com/docs/api/errors/21610",
"status": 400
}
Same shape for TermsAndConditionsUrl. Same outcome: registration fails, the Messaging Service stays in a pending state, and SMS through that service won't deliver until you complete the registration with valid URLs.
What stays working — and what doesn't
The trap here is that this isn't a flag-day cutover for delivery. Existing campaigns that were registered before June 30 continue to send messages.
What breaks is anything that triggers a re-registration or update:
- Creating a new Messaging Service for a new product, region, or environment
- Adding a campaign to an existing brand — even programmatically via the Trust Hub API
-
Modifying campaign fields — message samples, use case, sample message frequency. Any PATCH against
/v1/Campaigns/{sid}runs through the new validator. - Reapproving a flagged campaign — if a carrier flags a campaign for review (volume spike, content concern), the resubmission goes through the new schema.
- Migrating between brands — moving a campaign to a different A2P brand requires a fresh registration.
The pattern is: anything you do to A2P 10DLC after June 30 has to satisfy the new fields, even if the underlying campaign was approved years ago. A team that hasn't touched A2P registration since 2024 might not even realize their internal tools assume the old schema.
The fix
Update your campaign registration code to always include both fields. The current Twilio Node.js SDK shape:
await client.messaging.v1
.services(messagingServiceSid)
.usAppToPerson
.create({
brandRegistrationSid: 'BNxxxxxxxxxxxxxxxx',
description: 'Order status notifications and shipping updates',
messageSamples: ['Your order #1234 has shipped...'],
usAppToPersonUsecase: 'MIXED',
hasEmbeddedLinks: true,
hasEmbeddedPhone: false,
+ privacyPolicyUrl: 'https://example.com/privacy',
+ termsAndConditionsUrl: 'https://example.com/terms',
});
Same for the REST API directly — PrivacyPolicyUrl and TermsAndConditionsUrl are top-level form fields on POST /v1/Services/{sid}/Compliance/Usa2p.
Two things worth checking on the URLs themselves:
The URLs must be publicly reachable. Twilio fetches them server-side during registration. If they sit behind your auth layer, behind a staging-only domain, or only render with JavaScript, registration fails with a separate validation error that's worded like a generic "URL not accessible" message.
The privacy policy must mention SMS specifically. A generic site-wide privacy policy that doesn't reference SMS data collection or carrier opt-in handling can pass URL fetch but get rejected on content review by the carrier (T-Mobile is the strict one). The rejection arrives later, asynchronously, with a vague "campaign rejected by carrier" reason.
Why nobody's tests are going to catch it
This one fits the same pattern we keep seeing across our incident-intercept series, but with its own twist:
Unit tests don't catch it because the fields aren't required today. Tests pass against a sandbox that hasn't shipped the new validator yet. Twilio rolls staging changes ahead of production with usually a week or two of overlap, but the cutoff date itself isn't behind a feature flag — when it lands, it lands.
Integration tests don't catch it because most teams test message sending, not campaign registration. Registration happens once per Messaging Service, manually, often by a non-developer through the Twilio Console. There's no scheduled test that says "create a campaign and verify it accepts our payload."
The SDK doesn't catch it because the Twilio SDK doesn't enforce required fields client-side — it sends what you give it and lets the server validate. Adding a required: true to the Node.js typedef would help, but Twilio's typedefs lag the policy changes, and policy changes don't bump SDK majors.
Monitoring doesn't catch it because successful production message delivery doesn't exercise the registration path. Your Datadog dashboard will be green right up to the moment someone tries to add a new use case and the registration 400s.
Provisioning runbooks are where this hits hardest. Most teams have a runbook — code or wiki — for spinning up a new Twilio environment. That runbook captures the schema as it was the day it was written. If it was written in 2024 or 2025, it doesn't include these fields. The first person to use the runbook after June 30 will spend a confused hour figuring out why their carefully copy-pasted command 400s.
The carrier-rejection trap
Even when registration passes the Twilio API check, the campaign goes to the carriers (T-Mobile, AT&T, Verizon) for content review. T-Mobile in particular has tightened content review through 2025–2026, and they'll reject campaigns whose privacy policy doesn't:
- explicitly state that SMS opt-in data is not shared or sold to third parties for marketing
- include the program name and a description of the type of messages
- specify message frequency ("up to N messages per month") or that frequency varies
- list standard "Message and data rates may apply" language
Twilio's error in this case isn't a 400 on registration — registration succeeds. The campaign sits in a failed state hours later, and the API response surfaces a failure_reason that's frequently just "rejected by carrier" without specifics.
If your privacy policy is older than 2024 or hasn't been updated specifically for SMS, this is the more likely failure mode after June 30. Update both URLs and their content before the deadline.
How to actually catch this
For this specific change, three checks are worth setting up in May:
1. Audit your existing Messaging Services. Pull every Messaging Service and Campaign in your Twilio account and check whether privacy_policy_url and terms_and_conditions_url are set. The Twilio CLI:
twilio api:messaging:v1:services:list
twilio api:messaging:v1:services:compliance:usa2p:list \
--service-sid MGxxxxxxxxxxxxxxxx
The compliance API surfaces the campaign object with both URL fields. Anything blank is a campaign that will fail re-registration.
2. Pre-stage the URLs on every brand. Even if you're not registering new campaigns, having the URLs ready and resolving means you can update existing campaigns in place before June 30 without scrambling.
3. Diff Twilio's response shape over time. Twilio's API responses include the campaign schema. The fields go from optional to required without an API version bump — but the OpenAPI spec, the SDK typedefs, and the response payloads all evolve. Watching for those diffs is exactly the kind of thing schema-drift monitoring is built for.
That third one is what we've been building at FlareCanary. Point it at the Twilio Trust Hub API endpoints you depend on, and it polls on a schedule, learns the expected structure, and flags when a field's nullability changes, when a new required field appears, or when an enum tightens. Severity-classified so noise stays low.
You don't need a dedicated tool. You can cron a script that hits the relevant Twilio endpoints, hashes the field set, and diffs. The point is that some layer has to be watching response shape, because the carrier compliance world doesn't bump versions when it tightens — it just tightens.
The harder question
This is the second Twilio incident we've covered in the series. The first was the regional domain deprecation (api.de1.twilio.com going dark on April 28, 2026). Both have the same shape: a long pre-announced cutoff, a real public docs page, and a failure mode that doesn't show up in your day-to-day delivery metrics until a specific provisioning or re-registration path runs.
Most teams know what their Twilio bill looks like. Almost none of them have a list of every Messaging Service in every Twilio account, with a flag for which ones have the new compliance fields populated. That gap — between "what we use" and "what we'd find out about a schema change in advance of the cutoff" — is the same gap we see for OpenAI, GitHub, Stripe, Shopify.
A 200 response on a message send tells you SMS is delivering. It doesn't tell you the next campaign you try to register won't 400.
If you'd been diffing the Twilio campaign registration schema against a baseline since the announcement, you'd have seen the field requirement land in staging weeks before the production cutoff — long enough to update every runbook and every IaC file before the deadline ever became a problem.
That's the habit, and it generalizes to every API you don't control.
If you've been hit by an A2P 10DLC change that broke a registration path you hadn't touched in months — drop a reply. We've been collecting these and the pattern across providers is remarkably consistent.
