Get your 10DLC campaign ready for review.

1. Know what you’re registering.

A2P means application-to-person messaging; 10DLC means a ten-digit local phone number. For Twilio messaging to US recipients, the registration connects a business identity (the brand) to a messaging purpose (the campaign). Buying a number alone doesn’t finish that process. Toll-free verification and short-code provisioning are separate paths. Twilio’s A2P 10DLC overview.

Decide who the sender is before designing your account structure. A product sending its own notifications differs from a platform sending on behalf of independent customer businesses. Twilio has a separate ISV onboarding flow for registering customers’ brands and campaigns; don’t assume one platform registration covers every tenant. Twilio’s ISV onboarding guide.

2. Make the business identity consistent.

Gather your business registration details, website, address, and authorized contact before starting. For a US entity, Twilio asks for the legal name associated with the EIN, using the IRS confirmation documentation. A trading name on your homepage and a different legal name in the application need a clear, truthful connection. Required business information.

Our suggested review: open your homepage, contact page, policies, and registration draft side by side. Can someone unfamiliar with your product understand who operates it? Remove stale company names and placeholder pages. Record the brand and campaign identifiers in your own deployment notes so a future developer can trace the sender configuration.

3. Build an opt-in a reviewer can follow.

For a website checkbox flow, Twilio’s onboarding guidance calls for an unchecked consent control, a clear description of the messages, frequency, rate disclosures, help and opt-out instructions, and accessible policy links. Keep messaging consent separate from acceptance of general terms, and separate marketing consent from transactional consent. Don’t require messaging consent to complete an unrelated purchase or signup. Twilio’s campaign onboarding guidance.

Describe every way a person can enroll. A public form, an authenticated settings page, and a keyword signup are three different paths; a screenshot of one doesn’t explain the others. When reviewers can’t access the real flow, provide a publicly accessible evidence page with redacted screenshots and the steps needed to reach the consent screen. How Twilio evaluates message-flow evidence.

4. Publish the policies you actually follow.

Twilio’s privacy-policy rejection guidance looks for an explicit statement that mobile information and messaging consent aren’t shared with third parties or affiliates for their marketing or promotional purposes. Conflicting sharing language elsewhere in the policy can undermine that statement. Describe your actual handling of data rather than pasting a clause that contradicts your operations. Privacy-policy rejection details.

For new Twilio campaign API submissions from June 30, 2026, include both PrivacyPolicyUrl and TermsAndConditionsUrl. They must point to valid, publicly accessible pages. An older SDK or an API reference showing these fields as optional is not a reason to omit them: the dated registration requirement is explicit. Twilio’s June 2026 requirement.

Test those URLs while signed out, on a phone, and without a privileged network connection. Link directly to the relevant documents rather than to a homepage that makes a reviewer hunt for them.

5. Write a submission that describes the real flow.

Choose the use case that matches your traffic. Explain who receives messages, what triggers them, and what they contain. Include representative samples with the sender identity and actual link pattern you plan to use. Twilio’s campaign resource exposes separate fields for the description, message flow, samples, and content characteristics; keep them consistent. Campaign API fields.

The example below is an original draft for a fictional appointment service, Northstar Studio. It assumes an optional, unchecked appointment-text checkbox and no promotions. Replace every detail with your implemented behavior; it is not an approved template.

PrivacyPolicyUrl=https://northstar.example/privacy
TermsAndConditionsUrl=https://northstar.example/terms

The .example domain and bracketed reference are placeholders. Supply your real, reachable URLs and the required number of samples in your provider’s current form. Declare embedded links and other content attributes accurately; don’t omit a feature just to make the application look simpler.

6. Make the code keep the promises.

Review the consent state at send time, including for jobs scheduled before an opt-out. Our suggested record separates the person’s consent from delivery state and stores enough context to explain an enrollment later. Restrict access to this data and choose a retention policy appropriate to your obligations.

// Suggested application record, not a provider API payload.
type SmsEnrollment = {
  recipientId: string;
  programId: string;
  status: "subscribed" | "unsubscribed";
  consentedAt: string;
  consentSource: string;
  disclosureVersion: string;
  evidenceReference: string;
  optedOutAt: string | null;
};

With Twilio Advanced Opt-Out, incoming events can include OptOutType with START, STOP, or HELP. Twilio has already sent the configured keyword reply when that field is present, so don’t send a duplicate response. Persist the relevant subscription change and make your scheduler honor it. Advanced Opt-Out behavior.

Validate webhook signatures before changing consent state. Use Twilio’s supported validation helper and the request URL and parameters required by its documentation; a public endpoint that trusts an arbitrary POST can let someone else modify a subscription. Twilio webhook security.

Our implementation checks would cover: a queued job after STOP, a duplicate webhook, an invalid signature, HELP without a subscription change, and re-enrollment under the correct program. Track delivery callbacks separately from campaign approval; an approved campaign doesn’t mean each message was delivered.

7. Fix the specific rejection.

Keep the submitted text, evidence version, and returned review reason together. Treat a resubmission like a bug fix: identify the mismatch, correct the product or application, and check the same path again. Avoid changing unrelated fields at random.

There isn’t a reliable universal approval deadline to build your launch around. Keep production sending behind an explicit readiness check. In Twilio’s onboarding flow, the brand must be approved before campaign creation, and the sending number must be added to the appropriate Messaging Service. Check the campaign and number registration state before enabling traffic. Registration and sender setup.

Before you submit.

1. Walk through the real signup flow in a signed-out browser.
2. Verify that the brand, purpose, policies, and message samples describe the same service.
3. Open the evidence and policy URLs without special access.
4. Compare your submitted fields to what your production code actually sends.
5. Test consent capture, STOP, HELP, and queued-message suppression.
6. Save the submission and review result so a teammate can reproduce your checks.

The strongest submission is easy to verify. Spend your effort making the product behavior and its description agree, then use the provider’s current guidance to check the details.