Heads up on current processing times: We're seeing higher-than-usual submission volumes right now, so campaign reviews can take 5 business days.
- Overview
- Part 1: Campaign Details & Description
- Part 2: Message Flow
- Part 3: Sample Messages
- Part 4: Keywords & Automated Responses
- Part 5: Data Consistency & Common Rejection Reasons
Overview
All new A2P 10DLC Campaigns go through a vetting process to protect the messaging ecosystem for everyone and make sure everything aligns with carrier requirements and CTIA guidelines.
This guide will walk you through exactly what you need to prepare before you register, so you can get approved smoothly the first time.
Campaign Details & Description
This section is all about defining what your campaign is and who it's for. Let's break it down.
Campaign Use Case
(Console Label: Available A2P Campaign use cases | API Field: us_app_to_person_usecase)
Pick the use case that best matches your message content. Getting this right helps reviewers understand your campaign.
Standard Brand Use Cases
- 2FA: Authentication and one-time passwords
- ACCOUNT_NOTIFICATION: Updates about account status
- CUSTOMER_CARE: Support and account management messages
- DELIVERY_NOTIFICATION: Shipping and delivery updates
- FRAUD_ALERT: Spending alerts and potential fraud warnings
- HIGHER_EDUCATION: Messages from colleges and universities
- MARKETING: Promotional content, sales, and special offers
- POLLING_VOTING: Surveys and polls (non-political)
- PUBLIC_SERVICE_ANNOUNCEMENT: PSAs and community alerts
- SECURITY_ALERT: Notifications about compromised systems
- MIXED: When you're sending multiple types of messages (note: this comes with higher costs and lower throughput)
Low Volume Use Cases
- LOW_VOLUME: Great for brands that need to cover multiple use cases but won't be sending high volumes
- SOLE_PROPRIETOR: Specifically designed for Sole Proprietor brands
Special Use Cases
Some campaigns qualify as Special Use Cases, which can mean higher messaging throughput and lower carrier fees. A few of these are sensitive or critical and need additional approval. Learn more about special use cases.
Campaign Description
(Console Label: Campaign description | API Field: description)
Your campaign description needs to answer three questions:
- Who is sending the message?
- Who is receiving it?
- Why are they receiving it?
Your campaign description also needs to match the campaign type you selected and your sample messages. Keeping these consistent helps your registration get approved. Double-check that your campaign description matches your brand registration. If your brand name, website, or other details have changed since you registered your brand, make sure your campaign description reflects the current registered info to avoid rejection.
Please don't include any Personal Identifiable Information (PII) in the Campaign Description field. Publicly available info like brand names and phone numbers is fine.
If you're a financial institution engaged in direct, first-party lending, you must mention "Direct Lending" in your description, even if you're only sending OTP/2FA messages.
| This works | This doesn't |
| "Messages are sent by {Brand Name} to existing customers who have opted in. Messages include OTP codes for MFA logging into our online portal and security alerts regarding profile changes." | "We send texts to people." (Too vague, no brand, no recipient info, no purpose) |
| "Messages are sent by {Brand Name} to patients with upcoming appointments. Messages include appointment reminders, rescheduling options, and post-visit care instructions." | "John Smith at 555-123-4567 receives appointment reminders from our dental office." (Contains PII) |
| "Messages are sent by {Financial Institution} (Direct Lending) to loan applicants. Messages include application status updates and payment reminders." (Direct lending disclosed) | "Messages are sent by {ISV Name} to dental patients." (ISV registered instead of the actual dental practice) |
| "Messages are sent by {Brand Name} to customers who schedule service. Messages include appointment confirmations and vehicle ready notifications." | "Messages are sent by {ISV Name} to auto repair customers." (Platform/ISV name instead of end business) |
Message Flow
(Console Label: How do end-users consent to receive messages? | API Field: message_flow)
This is the heart of your registration, and it's also where most rejections happen. Your message flow needs to include a clear description of the opt-in method(s). If you use multiple opt-in methods for the same campaign (like both a website form and a keyword), provide a message flow for each of them.
In your message flow, we’re checking to make sure that the call-to-action and the right disclosures are displayed at the time of phone number collection. A call-to-action is the language that invites someone to sign up for your messaging program. Here’s what your message flow needs to include:
-
Service description and name
- Example: Sign up to receive shipping notifications from Twilio!
-
Fee disclosure
- Example: “Message and data rates may apply” (NOTE: In the US this verbiage is required verbatim, carriers won’t approve mockups that include the word "standard" as this implies the existence of premium rate messaging, which is no longer allowed in the US.)
-
Frequency
- Example: "One message per login", "Message frequency varies", "Three messages per delivery"
-
Customer care contact information
- Example: "Reply HELP for help"
-
Opt out instructions
- Example: "Reply STOP to opt out"
Message Flow Examples
Here are some examples of web form message flows for both marketing and transactional use cases:
Multiple Messaging Campaign Example (Express Written Consent)
Marketing Campaign Example (Express Written Consent)
Transactional Campaign Example (Express Consent) - Phone Number Field Optional
Transactional Campaign Example (Express Consent) - Phone Number Field Required
Here’s an example of a QR code message flow:
Here’s an example of a verbal message flow:
Twilio IVR: "As part of our service we can send you automated monthly text alerts regarding Twilio account payment activity. We will send two messages per month. Message and data rates may apply, depending on your mobile phone service plan. At any time you can get more help by replying HELP to these texts, or you can opt out completely by replying STOP. Mobile Terms of Service are available at http://twil.io/terms and our Privacy Statement can be found at https://twil.io/privacy. Please reply with 'yes' or 'no' to indicate if you would like this service".
Twilio Customer: "Yes please"
Twilio IVR: "Great! We will send you a text message to confirm your enrollment here shortly."
Here’s an example of a paper form message flow:
An in-store visitor completes a physical form that collects their phone number and their consent to subscribe to your texting campaign.
Note: Host a screen shot of the paper form on a publicly accessible website (like OneDrive or Google Drive) and provide the URL in the Message Flow Field.
Here’s an example of a message flow for a text message keyword campaign:
Note: For text (keyword) opt-in, you must also submit proof showing where end users see the phone number and keyword opt-in instructions. You may provide any of the following along with the opt-in disclaimer:
- Screenshot of the webpage or app where the number is shown
- Copy of the sign-up form or landing page
- Email or message where the number was shared with users
- Screenshot of the ad where the number appears.
Host a screenshot of the campaign collateral on a publicly accessible website (like OneDrive or Google Drive) and provide the URL in the Message Flow Field.
Getting consent right
The type of messages you send determines the level of consent you need. For transactional messages (order confirmations, appointment reminders), you need basic permission. This can happen when someone provides their phone number at checkout or verbally agrees over the phone. For marketing messages (sales and promotions), you need documented proof like a checkbox, form, or keyword opt-in. Verbal opt-ins aren't allowed for marketing messages unless you include a double opt-in via the user's handset to complete the express written consent requirement.
Consent applies per campaign. If someone signs up for order updates, they haven't automatically agreed to receive promotions. You need separate opt-ins for each campaign type. Enrolling a customer into multiple campaigns based on a single opt-in will get your campaign rejected. Consent also isn't transferable, can't be assigned to others, and can't be buried in general terms and conditions.
Consent needs to be voluntary. If customers have to opt-in to messaging to complete a purchase or create an account, your registration will be rejected. Here's what that means in practice:
- Users can't be required to opt-in as a condition for completing unrelated actions (creating an account, making a purchase, or accessing services).
- Messaging consent must be separate from terms of service, privacy policies, or other agreements.
- Consent controls (checkboxes, toggles) must be blank or off by default.
| This works | This doesn't |
| ☐ "Yes, I'd like to receive text alerts about my order" (Unchecked by default, voluntary) | ☑ "I agree to receive text messages" (Pre-checked box) |
| Separate checkbox for SMS consent, distinct from Terms of Service agreement | "By agreeing to our Terms of Service, you consent to receive promotional messages" (Consent bundled with ToS) |
| "Add my mobile number for delivery updates (optional)" | "Phone number required to complete purchase" with mandatory SMS opt-in |
| Separate opt-in for order updates vs. marketing messages | Single opt-in that enrolls customer in both transactional AND marketing campaigns |
Providing proof when opt-in isn't publicly visible
We need to be able to verify the opt-in method that you're describing. If your opt-in happens in any of the following situations, you'll need to provide a publicly accessible link to a screenshot (for example via Google Drive or OneDrive) directly in your message flow description:
- Behind a login or gated page
- On a paper form
- Via verbal script (IVR or agent)
- Not yet published publicly
- Part of an in-app flow
Privacy policy and Terms and Conditions
Every registration needs to include both a privacy policy and terms and conditions, and they need to meet specific requirements that protect your customers and keep you compliant with industry standards. Both are required for approval. In your privacy policy, Twilio checks for language that makes it clear that Messaging Consent data isn't being shared, sold, or bought. Here’s an example of the language we look for:
“All the above categories exclude text messaging originator opt-in data and consent; this information won’t be shared with any third parties.”
Your privacy policy must:
- Disclose what data you collect and how it’s used
- Explain that mobile information and opt-in consent won’t be shared with third parties or affiliates for marketing or promotional purposes (required by CTIA)
Your terms and conditions should generally include:
- Program or brand name
- Program description
- Message and data rates may apply disclosure
- Message frequency (or recurring message disclosure)
- Customer support contact information
- Complete opt-out instructions (HELP and STOP), displayed in bold
- Link to the privacy policy
- Disclosure that states "Carriers are not liable for any delayed or undelivered messages"
We recommend consulting with your legal counsel to make sure that your terms of service and privacy policy are compliant with applicable laws and consistent with standards for your particular campaign and industry.
Pro tip: Consider creating messaging-specific privacy policies and terms and conditions rather than updating your main company documents. Dedicated messaging policies are easier to keep current if requirements change.
Sample Messages
(Console Labels: Sample message #1, #2, #3... | API Fields: message_samples)
Provide 2-5 examples of what your actual messages will look like. This helps reviewers understand exactly what your customers will receive.
On Twilio Console, you’ll be able to check the following boxes:
- Messages will include embedded links: Check this if you're sending URLs
- Messages will include phone numbers: Check this if you're including phone numbers
- Messages include content related to direct lending: This one's critical. Check it if your campaign involves any loan arrangements.
- Messages include age-gated content: Check this if your content requires age verification (alcohol, tobacco, etc.)
The Twilio API includes the has_embedded_links field to indicate whether your campaign will send messages with links and the has_embedded_phone if your campaign will send messages with phone numbers.
Tips for strong sample messages:
- Use brackets for variables: Show dynamic content like [Name], [1234], or [Date]
- Include your brand name: Make it clear who's sending the message
- Add opt-out language: Include "Reply STOP to unsubscribe" in at least one sample
| This works | This doesn't |
|---|---|
| "Dental check due for {Name}. Visit {website} to schedule an appointment or call {Phone number}. Reply STOP to opt out." | "Here is your code." (No brand name, no context) |
| "Hi, is this the owner of 123 Oak St? I want to buy your house." (Cold outreach isn't allowed) |
Keywords & Automated Responses
You'll need to set up how your system responds to standard keywords. This is how your customers will manage their preferences.
Opt-In Keywords & Message
(Console: Opt-in Keywords | API: opt_in_keywords)
(Console: Opt-in Message | API: opt_in_message)
These are required if users can text a keyword to subscribe.
Keywords
Common ones include START, OPTIN, UNSTOP, IN (max 255 characters total)
Message
Include your brand name, confirmation of enrollment, help info, and how to opt out
Opt-In Confirmation (Required for all recurring campaigns)
No matter how someone opts in (web, paper, or text), they need to receive an immediate confirmation message. Here's what it should include:
- Brand Name or Program Name
- "Message and data rates may apply"
- Help contact info
- Opt-out instructions
- Frequency disclosure (like "Message frequency varies")
Example: "Welcome to Acme Alerts! You'll receive up to 4 msgs/month. Msg & data rates may apply. Reply HELP for help, STOP to cancel."
Opt-Out Keywords & Message
Required if you're managing opt-outs yourself (not using the default Twilio opt-out or Advanced Opt-Out).
Keywords (API: opt_out_keywords)
Common ones include STOP, UNSUBSCRIBE, END, QUIT, HALT (max 255 characters)
Message (API: opt_out_message)
Acknowledge the opt-out and confirm no more messages will be sent. Include your brand name.
| Field | What's Required | Example |
|---|---|---|
| Opt-Out Message | Acknowledge the request, state the brand name, confirm no further messages | You are unsubscribed from {Campaign Name} {Description} Alerts. No more messages will be sent. Reply HELP for help or {toll free number}. |
Help Keywords & Message
Required if you're managing help messages yourself.
- Keywords (API: help_keywords): Common ones include HELP, INFO, SUPPORT (max 255 characters)
- Message (API: help_message): Provide support options (email, website, or phone). Include your brand name.
| Field | What's Required | Example |
|---|---|---|
| Help Message | Provide a way to get support | {Campaign Name} {Description} Alerts: Help at {source of help #1} or {toll free number}. Msg&data rates may apply. {Message frequency}. Text STOP to cancel. |
Data Consistency & Common Rejection Reasons
Before you hit submit, take a few minutes to double-check these common issues. A little extra attention here can save you from starting over.
Keep PII Out of Registration Fields
Don't include real consumer names or phone numbers in your descriptions or samples. Use placeholders like [Name] or [555-555-5555] instead.
Make Sure Your Data Matches Up
Consistency matters a lot here. Reviewers will check that everything lines up:
- Brand Name: If you register as "Acme Inc" but your messages say "Contoso," reviewers will flag that mismatch.
- Email Domain: Corporate brands (like Twilio Inc) should use matching email domains, not gmail or yahoo addresses.
- Consistency across brand details: Your brand name, website, and email domain should all clearly connect to the same business. If they point to different entities, reviewers will flag the mismatch.
- Website: The URL you provide needs to be functional and represent the brand you're registering. Sites that don't load, return errors, or aren't live yet won't pass review.
- Third-party URLs: Links within the messaging content must represent the registered brand. Third-party redirects aren't permitted.
- ISVs: If you provide software for dentists, don't register your software company. Register the specific dental practice that's actually sending the messages.
- Duplicate Brands: Creating multiple brands with the same EIN or duplicate campaigns can slow down your approval.
Use Cases That Aren't Allowed
Some types of messaging will result in immediate rejection. Refer to our Help Article on Forbidden Message Categories in the US and Canada for more information.
Need more help? If your campaign gets rejected, our Campaign Rejection FAQ explains common rejection reasons and walks you through the resubmission process.