SMS Chatbot Setup

Passing 10DLC Registration on the First Try (2026)

Quick answer: Building the bot is the easy half. In the United States, nothing automated reaches a phone until a registry reviewer approves your campaign, and that review is a reading exercise: a person compares your campaign description, your sample messages, your written account of how people opt in, and the public web page where opting in supposedly happens, then checks whether all four tell the same story. Most of the rejection codes you are likely to hit are a mismatch between two of those four. So write them in the order that produces agreement, starting with the sample messages, and treat the registration form as a writing task rather than an engineering one. This guide walks that order, then covers wiring the bot to replies, testing before you point a list at it, and what to do when a campaign comes back rejected. What an SMS chatbot is, why the channel has no buttons, and how segment billing works all live in our SMS chatbot glossary entry; this page is the doing.

A note on sourcing before you rely on any of it. The field limits, rejection reasons and content restrictions below are quoted from Twilio's published documentation, because Twilio documents this process in more public detail than any other provider we could find. The underlying registry requirements are common to all US senders, but the exact wording, the error codes, the console paths and the forbidden-content list are Twilio's. If you are registering through SendPulse, Manychat, Bandwidth, Sinch or anyone else, expect the same shape and check the specifics against your own provider's documentation.

What this guide assumes you have already settled

Three decisions sit upstream of this page and are not re-argued here.

That SMS belongs in your channel mix at all. It is the most expensive per message and the most constrained of the mainstream options, and our channel selection guide is the honest place to test whether your customers would answer a text from you. If your audience is already reachable on a free channel with buttons, start there.

That SMS rather than RCS is the right lane for this campaign, which our RCS versus WhatsApp comparison covers from the budget side.

And that you accept the registration gate as a schedule item, not a formality. Twilio's onboarding documentation describes the overall process as taking two to three weeks, with a separate banner reporting that campaign reviews were "currently taking 10-15 days" because of a surge in submissions. Read the banner as a temporary backlog notice rather than a competing baseline. Plan in weeks, and plan for at least one rejection: the published rejection reasons are numerous and specific enough that first-attempt approval is not the safe assumption, though nobody publishes a first-pass approval rate and we are not in a position to estimate one.

The four documents a reviewer compares

The campaign registration form looks like a set of unrelated boxes. It is better understood as four documents that have to agree, plus one page on the open internet that has to corroborate them.

Two rules make the agreement requirement sharper than it first sounds. Twilio publishes a rejection code for campaigns where "the same text was copy-pasted across multiple registration fields, or all sample messages are identical," so the four documents have to be consistent without being duplicates. And the reviewer is explicitly checking that they can reach the opt-in experience themselves: another code covers websites that require a login, because "reviewers cannot access it."

Step 1: write the two sample messages first

This inverts the order of the form, and it is the change we would make first. The sample messages are the most concrete thing you will produce, and everything else has to be consistent with them, so writing them first means the descriptions get written against a fixed target instead of the other way round.

Twilio's published requirements for samples are specific. They must align with both the campaign description and the selected use case. The brand has to be identified by name or website in each message. Variable content goes in square brackets. And if your real messages will contain links or phone numbers, the samples have to contain them too, because a separate rejection code exists for campaigns that declare embedded phone numbers but do not show one in a sample.

A workable pair for a small business looks roughly like this:

Acme Sandwich Co: Your order [#1042] is ready for pickup at [Elm Street]. Reply HELP for help, STOP to cancel.

Acme Sandwich Co: [Tuesday] special is [two subs for $12], today only. Details: acmesandwich.com/deals Reply STOP to cancel.

Three things that pair does deliberately. The brand name opens both. Every variable is bracketed. And the two messages are visibly different from each other, which matters because identical samples are a named rejection reason.

One trap has its own error code, and it is easy to hit while getting everything else right. Public link shorteners are not allowed. Twilio's guidance is that "you must use a dedicated, branded short domain that belongs to your business," and that a randomly-shortened link from a free service such as bit.ly or TinyUrl "will lead to rejection of the Campaign by TCR." CTIA's industry guidance says the same thing in principle, asking that any shortener use "a web address and IP address(es) dedicated to the exclusive use of the Message Sender." Links should also be https rather than http, which is its own rejection code. If you do not have a branded short domain, put the full URL in the message.

Step 2: build an opt-in page a reviewer can open

The registration form asks you to describe consent. The reviewer verifies it. Twilio's documentation for the call-to-action rejection code says reviewers check for a collection mechanism, the required disclosures, public verifiability, and that every opt-in path is listed. Three of those four are properties of a web page, so build the page before you describe it.

What that page needs, in the reviewer's terms:

• A checkbox specifically for SMS consent, unchecked by default. A pre-selected box is its own rejection code, and so is a form whose single button grants all permissions at once. The consumer has to be able to decline messaging and still use your service.
• Marketing consent kept separate from transactional consent. If one checkbox covers both order updates and promotions, that is a named rejection reason. If you only send transactional messages, say so explicitly in the campaign description.
• Four disclosures near the checkbox: what kind of messages, how often, "message and data rates may apply," and how to stop. Missing any of them is a code.
• A privacy policy at a public URL that states you will not share mobile numbers with third parties for marketing, discloses message frequency, and carries the rates disclosure. Login-gated policies are rejected. So are terms pages that live on a different domain or sit behind an authentication wall as PDFs.
• A website with actual business context. Separate rejection reasons exist for sites that are just a lead-capture form, sites under construction, and sites that do not otherwise establish what the business is.

If consent genuinely happens somewhere a reviewer cannot go, on paper in your shop or behind a customer login, the documented route is to host an image of that form at a public URL and give them the link. That is an accepted pattern, not a workaround.

One more detail that catches small businesses: the brand's support email should be on your own domain. A contact address at gmail or yahoo is a named rejection reason, and it is a fast fix if you catch it before submitting.

Step 3: describe every opt-in path, not the main one

The opt-in field, called message flow in the API, carries more distinct rejection codes than any other single field, which is a reasonable proxy for how much attention it gets. The guidance is blunt: "If multiple opt-in methods can be used for the same campaign, they must all be listed," and reviewers reject campaigns that account for only one of several active paths. A campaign that collects numbers on a web form and also accepts a text-in keyword and also takes numbers at a counter has three paths, and all three go in one field.

The difference between a passing and a failing version is entirely specificity. "End users opt in on our website" fails, because it names no URL, links to no policy, and describes no mechanism. A passing version names the exact signup URL, describes the checkbox and what it says, states the message frequency and the rates disclosure, and links the terms and privacy pages by address.

Write it as a walkthrough in plain sentences. Where does the person start, what do they see, what do they click, what happens next, and where can the reviewer read the terms. If a keyword path exists, quote the keyword and the confirmation reply verbatim. If a paper path exists, name the hosted screenshot URL.

Step 4: write the campaign description last

By now the description almost writes itself, which is the point of the order. Twilio's requirement is that it "should include who the sender is, who the recipients are, and why messages are being sent to the recipients," and that it align with the use case you selected. Its worked example is one sentence: a campaign sending weekly marketing messages about sales and offers from a named sandwich company to customers who have opted in.

Two failures are common here. A description that is vague enough to describe any business fails, because the reviewer cannot match it to anything. And a description that does not match the selected use case fails as its own code, which usually means somebody picked a use case from a dropdown before writing the description rather than after.

Registration fields also have to be in English, which is a named rejection reason worth knowing if you operate in another language. Your messages can be in any language; the paperwork about them cannot.

If your business does direct lending or anything age-gated, declare it explicitly, and check with your provider where that declaration belongs. Twilio's older instructions say to state direct lending in the free-text campaign description; its newer documentation describes structured checkboxes for direct lending and age gating, but that documentation is currently marked as a private beta, so the checkboxes may not exist in your console. Both sets of instructions are live at once. Declaring it in the description costs nothing if a checkbox also exists, and omitting it has its own rejection code.

Step 5: set the three keyword replies

Three automatic replies are part of the registration, and each has published content requirements and a 20 to 320 character range.

The opt-in confirmation should carry the brand name, confirm enrollment in a recurring campaign, say how to get help, and state clearly how to opt out. The opt-out confirmation must acknowledge the request and confirm that no further messages will be sent; naming the brand is recommended. The help reply has the most mechanical requirement of the three, and therefore the easiest one to fail by accident: the rejection reason reads "HELP message reply does not contain brand name, phone number, or email address." Put all three in it.

Two things about opt-out keywords are worth getting right, because both circulate widely in the wrong form.

The keyword list you have probably seen, STOP plus STOPALL, UNSUBSCRIBE, CANCEL, END, QUIT, OPTOUT and REVOKE, comes from carrier and vendor implementations; Twilio's messaging policy lists it in that shape. It is not CTIA's list. CTIA's Messaging Principles and Best Practices asks that "standardized 'STOP' wording should be used for opt-out instructions," and then names a shorter set of natural-language variants that should also be honored: stop, end, unsubscribe, cancel, quit, and the phrase "please opt me out." Attributing the vendor keyword list to CTIA is a small error, but it is the kind that makes a compliance document look copied rather than read.

The second point is the operationally useful one, and it has a carve-out that most summaries drop. CTIA says the validity of an opt-out "should not be impacted by any de minimis variances in the Consumer opt-out response, such as capitalization, punctuation, or any letter-case sensitivities." So if you handle opt-outs in your own bot logic, case-fold and strip punctuation. But CTIA qualifies the natural-language part: those variants should be acted on "except where a specific word can result in unintentional opt-out." That exception matters precisely because of the use case this guide recommends. If your bot handles appointments, a customer texting "cancel" almost certainly means the appointment, not the subscription, and treating it as an unsubscribe silently deletes a customer who wanted to talk to you. Reserve the bare standardized keywords for opt-out, and route the ambiguous natural-language ones through a confirming question instead of a silent removal.

Step 6: wire the bot to inbound replies

Only now does this become a chatbot project, and the channel makes it a harder one than it looks. The reason is the missing interface, which our glossary entry argues at length and this page takes as given: with no buttons to fall back on, an SMS bot needs stronger language understanding than the same bot on a widget.

Three wiring decisions matter more than the rest.

Decide what the platform intercepts and what reaches your flow. Most platforms handle STOP and HELP before your logic sees the message. That is usually what you want, but you need to know it, because a flow that also tries to answer HELP will either double-reply or never fire, and testing will not tell you which until you look at the logs.

Give the bot one job and a fast exit. The reply volume on a well-targeted SMS campaign is small and high-intent, which makes a narrow bot plus a quick handoff to a person a much better shape than an ambitious tree. Our escalation playbook covers the handoff design; the SMS-specific part is that a customer who has to text three times to reach a human is paying for each attempt in attention, and there is no visible menu telling them they are close.

Write the fallback for a channel with no affordances. When the bot does not understand, it cannot show a menu, so the fallback has to offer the options in text and keep them short. Our fallback rate guide covers the measurement loop; on SMS the specific discipline is that every fallback costs a segment and a little patience, so two failures in a row should route to a person rather than try a third time.

Step 7: test before you point a list at it

Test on real handsets, not on a simulator, and not only on your own phone. The list below is the SMS-specific subset of our fuller pre-launch testing protocol.

• Send every sample message you registered, verbatim, to a real phone. Check that the brand name renders, the links resolve over https, and the message did not silently split into more segments than you expected.
• Text the opt-out keyword and confirm you get exactly one confirmation and then nothing. Then text it in lowercase with a period after it, and confirm the same thing happens.
• Text HELP and read the reply as a stranger would. Brand name, a way to reach a human, and no jargon.
• Text the opt-in keyword from a number that has never messaged you and check the confirmation content against what you registered.
• Send something the bot cannot answer, twice, and confirm the second failure routes to a person.
• Walk your own opt-in page on a phone, not just on the desktop layout you built it in. Confirm the SMS checkbox is genuinely unchecked, that the disclosures are visible next to it rather than pushed below the fold, and that the privacy and terms links are tappable.

Then the part that matters after launch: send what you registered. Campaign-to-traffic mismatch, where "in-market traffic does not match with the campaign registered," is the first item on the published list of reasons an approved campaign gets suspended. Approval is not permanent, and a promotional blast sent under a transactional registration is the classic way to lose a working channel.

When the campaign comes back rejected

Rejections split into two tiers, and the first thing to establish is which one you are in.

Most rejection reasons are eligible for resubmission. Twilio's mechanic is to edit the rejected campaign rather than delete and recreate it, because the vetting fee is assessed once per campaign and deleting starts that over. There is no stated limit on the number of resubmissions. In Twilio's console the path is Messaging, then Regulatory Compliance, then Campaigns, then the failed campaign, then Edit Campaign.

One caveat, disclosed because we could not fully resolve it: Twilio's pages do not all agree on whether a resubmission incurs a new vetting charge. Two of them, including the rejection-code article this section draws its taxonomy from, say the fee applies once per campaign and that deleting and recreating triggers a new one. An older page says a fee will be assessed on resubmissions after a failed third-party vetting review. The majority position is the first one, and it is the one we follow, but confirm it with your own provider before planning around it. We quote no dollar figures anywhere on this page, for the same reason the glossary entry does not: registration fees move.

There are two situations where editing will not work and deleting is the only path. If the rejection says the use case itself is wrong, as distinct from the use case description, the campaign has to be recreated. And if the problem is with the brand rather than the campaign, you are stuck, because a brand cannot be edited while any campaign is registered against it.

Map the rejection to the document. Most eligible codes point at exactly one of the four, and the handful that do not are usually about business identity rather than about your campaign: a contact address on a public email domain, registration fields written in a language other than English, one company registering more brands under a single tax ID than it needs, or a business that has hit the cap on campaigns per brand. Those are fixed by changing the fact, not the wording.

The rejections you cannot fix by resubmitting

A second tier exists for forbidden content, and these are not resubmission problems. They are business-model problems, and the honest thing a guide can do is tell you before you spend three weeks. One caveat first: not everything that sounds like a content problem sits in this tier. A missing or inadequate age gate is a rejection code you can fix, by building a proper age gate and resubmitting. What follows is the tier where rewriting will not help.

Twilio's prohibited categories for US messaging include high-risk financial services such as payday and short-term high-interest loans, cryptocurrency and stock or investing alerts, debt collection and debt reduction, credit repair, third-party lead generation, gambling, get-rich-quick schemes, prescription drugs, and phishing. Cannabis, CBD, kratom and paraphernalia are prohibited outright on Twilio in the US and Canada, and the position is unusually absolute: the restriction applies "regardless of the federal or state legality," to all use cases for such businesses "whether it contains cannabis content or not, even for 2FA purposes." Other providers publish their own lists, and Twilio itself publishes a second, non-identical one elsewhere, so check your provider's version before concluding either that you are barred or that you are clear.

The SHAFT categories, sex, hate, alcohol, firearms and tobacco, are handled with more nuance than the acronym suggests, and some of them are the fixable kind. Alcohol traffic is allowed on US routes with proper age gating, where age gating specifically means the user enters a date of birth rather than answering a yes-or-no question; build that and the rejection goes away. Firearms, vape and e-cigarettes are not allowed on long code, toll-free or short code regardless of age gating, which puts them in the genuinely blocked tier. Tobacco is allowed on short code with age gating but not on long code or toll-free, so for tobacco the constraint is which sender type you can use rather than whether you can send at all.

A small factual note, since compliance pages copy each other freely: CTIA's Messaging Principles and Best Practices does not contain the word SHAFT and does not enumerate those five categories. Its prohibited-content section is written in general terms about unlawful, deceptive and unwanted content. SHAFT is defined in CTIA's separate Messaging Security Best Practices document and is used extensively by carriers and vendors. Nothing about the practical restrictions changes; the citation does.

If you land in this tier and believe it is a misclassification, an appeal path exists. The published instruction is to contact support with the details and the subject line "10DLC Campaign Appeal for (your business name or number)."

Platform notes

Our glossary entry sets out the two questions to ask any vendor about this channel, and its survey of who supports what stands. The registration-specific version of the second question is the one to press on here: find out, in writing, whether the platform submits your 10DLC brand and campaign for you, hands you a form to fill in and submits it on your behalf, or expects you to bring your own carrier account and register separately. Those are three different projects, and the third one means the runbook above is entirely yours to execute.

Our reviews carry affiliate links, and each records what was verified at its own date. Among the products we cover, SendPulse carries SMS alongside its chat and email channels; Manychat offers SMS next to its social-messaging core; our Intercom review documents outbound SMS and leaves full two-way automated flows as something to confirm with their sales team. WhatsApp specialists such as Wati and general builders such as BotPenguin come at the channel from other directions. One thing worth stating plainly for anyone arriving from the WhatsApp side: a vendor's Meta approval experience predicts nothing about how it handles a 10DLC submission, because the two regimes share nothing but the word approval.

Frequently asked questions

Related guides

• SMS chatbot (glossary) — the definition, the design constraints of a channel with no interface, segment billing, and the consent-law correction
• Choose your chatbot channels — whether SMS belongs in your mix before you register anything
• RCS vs WhatsApp for business — the campaign-lane decision that sits next to this one
• WhatsApp chatbot tutorial — the other approval-gated channel, and a useful contrast in how differently the two regimes work
• Telegram chatbot setup — the same build with no gate at all, for comparison
• Chatbot QA testing protocol — the fuller pre-launch test set this page draws its SMS subset from
• Chatbot escalation playbook — the handoff design an SMS bot leans on harder than most
• Reduce chatbot fallback rate — the measurement loop for a channel where every retry costs money
• Chatbot broadcast (glossary) — the one-to-many layer, if you do not actually need a conversation

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. It tells a meaningful share of readers that their business category cannot send SMS at all, and tells others that a free channel would serve them better, both of which argue against the purchases we earn on. We have a mild commercial interest in readers choosing platforms through our reviews. This is editorial guidance, not legal advice, and consent obligations under the TCPA and state law are a question for counsel. To flag an error, write to editorial@chatbotscape.com.

Methodology

This page contains no new measurements. We did not submit a 10DLC campaign for it, we have never had one reviewed, and no timeline, approval rate or rejection frequency here is our own observation. Every registration mechanic, field limit, rejection reason and content restriction is quoted or paraphrased from the vendor and industry documentation cited below, retrieved and read on 30 July 2026, with each quoted string checked against the page it is attributed to.

The single most important scoping note: the operational detail on this page is Twilio's, not the registry's and not an industry standard. Twilio publishes this process in more public detail than other providers, which makes it the most useful source available and also means the error codes, console paths, character limits, forbidden-content list and correction instructions are one company's implementation of shared carrier requirements. We have tried to attribute it that way throughout rather than writing "the registry requires." Readers on other providers should treat the structure as transferable and the specifics as needing local confirmation. Twilio's own documentation also disagrees with itself in places, and we name those disagreements rather than averaging them: the opt-in field's character maximum, whether a resubmission incurs a new vetting fee, and whether the structured direct-lending and age-gating flags are generally available or still limited to a private beta.

Registration and vetting fees are described structurally with no dollar amounts, because they change, which is the same policy our SMS chatbot entry follows. Timelines quoted are the ranges providers publish, vary with how much vetting a brand requires, and are not commitments. The sample messages in Step 1 are original editorial examples written to illustrate the documented requirements; they have not passed a real review. The four-documents framing, the write-the-samples-first ordering, and the rejection-to-document mapping table are our editorial framing rather than a published standard, and the suggestion that a shortener alone could trigger a traffic-mismatch suspension is labeled in the body as our inference. The recommendation to plan for at least one rejection is an anchored editorial assessment drawn from the number and specificity of published rejection codes, not a measured approval rate; nobody publishes a first-pass approval rate and no such figure should be trusted from us or from anyone else who has not published a method. Where the page notes that one field carries more rejection codes than another, that is a count of published codes and not a claim about how often each one fires. Platform notes are structural, trace to our published reviews at those reviews' own dates rather than being re-checked here, and vary in evidence depth per review, which is why the Intercom note names what its review left unverified.

Sources

• Twilio Docs. A2P 10DLC: collect business information. twilio.com (fetched and verified 30 July 2026. Source of the field definitions and character limits for campaign description, message flow, message samples and the three keyword auto-replies, and of the privacy policy and terms acceptance criteria).
• Twilio Docs. Error 30909: Campaign rejected, Message Flow or Call to Action incomplete or unverified. twilio.com (fetched and verified 30 July 2026; source of the four checks reviewers perform, the passing and failing opt-in descriptions, and the edit-rather-than-recreate resubmission mechanic. This page is not marked as beta, which is why we cite it rather than the troubleshooting page for that mechanic).
• Twilio Docs. Troubleshooting and rectifying A2P campaigns. twilio.com (fetched and verified 30 July 2026. Source of the branded-shortener requirement, the two cases where a campaign must be recreated rather than edited, and the list of post-approval suspension triggers including campaign-to-traffic mismatch. Note that this page states its campaign-edit sections are available only to participants in a private beta, which is why the structured direct-lending and age-gating flags are scoped as beta in the body. An older sibling page disagrees with it on the resubmission vetting fee; that disagreement is disclosed above rather than resolved).
• Twilio Docs. A2P 10DLC direct standard onboarding. twilio.com (fetched and verified 30 July 2026; source of the two-to-three-week process estimate and of the surge banner reporting campaign reviews at 10 to 15 days).
• Twilio Help Center. A2P 10DLC Campaign Registration Rejected. support.twilio.com (content read and verified 30 July 2026 at this address. Twilio's current Help Center at help.twilio.com is client-rendered and returned no readable text on retrieval, so the still-live support mirror linked here is the artifact we actually read; that mirror carries an end-of-life notice, so treat the citation as accurate as of the retrieval date and expect the address to change. Source of the enumerated rejection codes, the eligible and ineligible tiers, the granular opt-in and website codes, the age-gate code's placement in the eligible tier, and the appeal subject-line instruction).
• Twilio Help Center. Forbidden Message Categories in the US and Canada. support.twilio.com (fetched and verified 30 July 2026; source of the prohibited-category list, the cannabis position quoted above, and the per-route age-gating rules for alcohol, tobacco, firearms and vape. Two caveats: the page's own stamp reads "Updated August 21st, 2023" while its content clearly postdates that, and it sits on the same mirror carrying an end-of-life notice. Twilio also publishes a second, non-identical forbidden-content list elsewhere. Cited for the categories quoted here rather than as a complete or current inventory, and the body says so).
• Twilio. Messaging Policy. twilio.com (fetched 30 July 2026; cited here only for the opt-out keyword list that this page attributes to vendor and carrier practice rather than to CTIA. The page displayed no effective date on our retrieval; our SMS chatbot entry records one, and readers should check the live page).
• CTIA. Messaging Principles and Best Practices, May 2023 edition. api.ctia.org (full text read and searched 30 July 2026; source of the opt-out language and the de minimis variance standard, the call-to-action disclosure list, the consent tiers, and the embedded-link guidance. Verified by full-text search not to contain the term SHAFT, contrary to widespread secondary claims. This is the current edition as of the retrieval date; it supersedes the 2019 edition by its own statement).
• CTIA. Messaging Security Best Practices, October 2025. api.ctia.org (fetched 30 July 2026; the document that actually defines SHAFT as "content related to sex, hate, alcohol, firearms, or tobacco," and a separate publication from the Messaging Principles above).
• Chatbotscape Glossary. SMS chatbot — carries the definition, the design-constraint analysis, segment billing, the sender-type taxonomy, and the consent-law correction this page defers to (verified 28 July 2026).
• Chatbotscape platform reviews for SendPulse, Manychat, Intercom, Wati and BotPenguin, last updated between 27 and 31 May 2026. Channel notes here are structural and stated as of each review's own date; evidence depth differs per product and is recorded per review.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

Last updated

1 August 2026 — Initial publication aligned to methodology v3.12.1. Registration mechanics verified 30 July 2026. Next scheduled refresh: 1 November 2026, or sooner if the registry changes its campaign-vetting requirements.