A2P 10DLC approval: what actually gets a campaign through

What A2P 10DLC actually is

A2P means application-to-person: a message your software sends to a human being. 10DLC means it goes out over a ten-digit long code — a normal local number, not a short code and not a toll-free number. US carriers require that traffic to be registered before they will carry it, and the registration has two parts.

• The brand — who you are. Legal business name, tax ID, registered address, website, industry. It is identity, and it is checked against the record the tax authority holds.
• The campaign — what you intend to send, to whom, and how those people agreed to receive it. Use case, sample messages, opt-in method, opt-out and help wording, and links to the policies that back all of it up.

The part that catches people out is the failure mode. Unregistered or unapproved traffic is not returned to you as an error you can read. It is filtered. The API call succeeds, you get a message identifier back, your logs look healthy, and nothing lands on a handset. There is nothing to debug, because nothing broke — you never had permission to send.

Two things are worth separating early. Voice is unaffected: a number can answer and hold a conversation while messaging is still in review. And your provider does not decide — it passes the filing to the registry the carriers read. Arguing with support does not move a campaign; changing the filing does.

Failure one: the brand does not match the legal entity

This is the first wall most businesses hit, and it has nothing to do with messaging. The brand record has to match the entity as the tax authority knows it — not the name on your sign, your invoices or your website header.

Our own case is the textbook version. The legal entity is The Art of Marketing LLC; SAIDA is its registered trade name. The brand goes in as The Art of Marketing LLC, with that entity's EIN and registered address, and SAIDA goes in the DBA field. Put the trading name in the legal-name field and the record fails vetting, because no tax record exists for a company by that name.

Four things have to agree with one another, and the reviewer looks at all four:

• The legal name, spelled and punctuated as it is filed — including "LLC" or "Inc." and any comma you would normally drop.
• The EIN, matched to that exact name. A digit typo reads as a different company.
• The registered address on file, not the address where you actually sit if the two differ.
• The website, which the reviewer will open. If the site never mentions the legal entity, that is a mismatch too. We put the disclosure in the footer and repeated it on the privacy policy and terms. One sentence, and the identity question closes.

Same family, cheaper fix: use a support address on your own domain. Free webmail in a brand filing reads as unverifiable.

Failure two: the reviewer checks a page, not your prose

The campaign form gives you a generous free-text box to describe how people consent, and it is tempting to write a careful paragraph and consider the question answered. That paragraph is a claim. The reviewer wants evidence, and evidence means a URL they can open.

We lost a round to exactly this. Our campaign said people opt in by texting our business number first — true, and a perfectly good consent method. But the number appeared nowhere on the public internet: the footer disclosure described the program without printing the number, and the only phone number on the site was a voice line. The rejection came back as no proof provided for text opt-in. It was correct. There was nothing to look at.

The fix was a page. We built a dedicated disclosure page showing the exact number, stating plainly that texting it is how you opt in, what you will receive and how often, the opt-out and help wording, the rates line, a statement that consent is not a condition of any purchase, and links to the policies. Then we pasted that URL into the campaign, and the next round cleared the opt-in question.

The logic holds for any consent method. A web form has to be reachable without a login, with the checkbox unchecked by default and the disclosure beside it. A paper form needs an image. A verbal yes needs the script and the enforcement described below. Screenshots help; a live URL is stronger.

Failure three: the dedicated URL fields you left blank

This is the one that cost us the most rounds, and it is the stupidest.

Registration forms have separate, dedicated fields for the privacy policy URL and for the terms or message-flow URL. They sit apart from the long description box, they are easy to scroll past, and in our interface they were not marked required. We had both URLs written into the description prose, in a sentence that read perfectly well to a human. The dedicated fields went in blank.

We were rejected twice in a row on privacy and terms, while both pages were live, correct, linked in the footer, and said everything they needed to say. The reviewer never saw them. A blank dedicated field does not read as "look in the paragraph". It reads as "no policy exists".

Failure four: your own legal pages contradict you

This one only appears once you register a second program, which is why almost nobody warns you about it.

Our privacy policy said that texting us first is our only opt-in method — accurate, and helpfully specific, for the one program we had. Later we registered a second program on a different number, where consent is captured verbally during a call. The reviewer opened the privacy policy we had just handed them, found a sentence excluding the exact consent method the new campaign described, and rejected it. The filing contradicted its own evidence.

Two habits came out of that, and we run both before any new campaign goes in:

1. Every distinct SMS program gets its own labeled block in both legal pages. Not one merged paragraph covering "our text messages" — a block per program, in the privacy policy and again in the terms, naming who receives messages, how consent is captured, what gets sent, how often, and how to stop.
2. Every absolute gets re-scoped. Search both pages for "only", "always", "never", "all" and "sole". Each one either belongs to a named program — "for the maintenance line, texting us first is how you opt in" — or it goes. An absolute written for your first program is a landmine under your third.

Treat the legal pages as part of the filing, not as something you wrote once. Order matters: publish the pages, confirm they are live, then submit the campaign that points at them.

A consent story for verbal opt-in on a phone call

Verbal opt-in has a bad reputation because it is easy to do badly. Done properly it is defensible, and it fits a line someone has already called. This is the shape behind the confirmation text our AI receptionist sends at the end of a booking call:

• The caller phoned us. The conversation is inbound; nobody is cold-texted off a list.
• They were asked out loud, in plain words, whether the number they are calling from can receive one confirmation text. Not buried, not assumed from the fact that they called.
• Only their own number is texted. The destination has to equal the caller ID on the line. A number read out for a spouse or an office is not that person's consent.
• Consent is enforced in code, not in a prompt. This is the part people get wrong: a model told never to text without permission will eventually text without permission. The send function refuses to run unless the consent flag is set and the destination matches the caller ID, and it logs the yes with a timestamp. A rule a model can talk itself out of is not a control.
• One message per booking. No follow-up sequence, no reminder drip, no marketing riding in on a transactional yes.
• Consent is never a condition of service. Say no and the appointment is booked exactly the same way.
• Opt-out wins forever. A stored STOP outranks any later verbal yes, and the check runs before the message is composed.

Write that story into the campaign in the same order, and put the line you actually say into the opt-in description. It reads as a system rather than an intention, which is the whole difference. If your line touches health information, consent is the small question inside a bigger one — the rest is in putting an AI on the front desk without breaking HIPAA.

What has to be inside the messages

Sample messages are read closely and compared against what your code actually sends. Make them the literal strings, with variables shown as variables, and make sure each one carries:

• The business name, in the first message. "Your appointment is confirmed for Tuesday at 2" from an unknown number identifies nobody.
• "Reply STOP to opt out, HELP for help." At minimum on the first message of a conversation; where there is only ever one message, that means every message.
• Message frequency, stated concretely: one message per booking, or per request, or message frequency varies.
• "Msg & data rates may apply."
• A non-sharing statement, on the disclosure page and in the privacy policy: mobile numbers and SMS consent are never shared with third parties for marketing. Reviewers look for that sentence, and its absence reads as a gap.

Two smaller traps. The content-attribute checkboxes — links, phone numbers, age-gated content — have to match your samples; a phone number in a sample with the box unticked is a contradiction visible at a glance. And the use case has to describe your real traffic: a confirmation text is customer care, and dressing marketing up as customer care because that path looks easier ends the same way.

Rejection triage: what to actually change

Rejections arrive as a short code and a one-line reason that rarely names the field needing the change. These are the ones our own filings came back with, and what each turned out to mean. Your provider may surface different codes; the reasoning underneath is the same.

What you are told	What it usually means	What to actually change
Brand mismatch	Legal name, EIN or address does not match the tax record — usually a trade name filed as the legal name	Re-file with the exact legal name and EIN; move the trading name to the DBA field; put the entity name on the website
No proof provided for text opt-in	The reviewer could not find a public page showing the number and the opt-in instruction	Publish a disclosure page with the number, the call to action, frequency, STOP/HELP and rates, then paste that URL into the campaign
Privacy policy	The dedicated privacy URL is blank, or the page never mentions SMS	Fill the dedicated field; add an SMS section saying mobile numbers and SMS consent are not shared with third parties for marketing
Terms and conditions	The dedicated terms URL is blank, or the terms carry no message-program section	Fill the dedicated field; add a block per program with frequency, STOP/HELP wording and the rates line
Use case mismatch	The samples or description do not match the declared use case	Pick the use case that describes your real traffic; rewrite the samples as the literal strings your code sends
Content attributes	The checkboxes contradict the sample messages	Tick them truthfully, then re-read every sample against every box

One habit shortens every round after the first: save the complete field set you submitted, exactly as it went in. When a rejection lands you want to diff two versions, not reconstruct what you typed three weeks ago.

Operational notes nobody tells you

Registration runs in weeks, not days, and every rejection restarts the clock — which makes it a scheduling problem rather than a technical one.

Each business you serve needs its own brand and campaign, under its own tax ID. You cannot put a client's traffic under your own registration. The brand is the business that has the relationship with the recipient, and everything hangs off that — their EIN, their consent, their disclosures, their number, their page. Pooling several businesses under one registration is how an entire number pool ends up filtered.

A material change is a new campaign, not a quiet edit: a different consent method, a different audience, a different kind of content. Update both legal pages first. We treat the packet as one deliverable — pages, filing, and the code that enforces consent, changed together or not at all. Same principle as the rest of our work order automation: the system and its paperwork describe each other, or one of them is lying.

The checklist to work through before you file

Work down this list before you open the form. Every line came from a round we lost.

1. Legal name and EIN exactly as the tax authority has them; the trading name in the DBA field.
2. The legal entity name visible somewhere on the website — the footer is fine.
3. A support email address on the company domain.
4. A public page showing the number and the exact opt-in instruction, with frequency, STOP/HELP, rates and the not-a-condition line.
5. A privacy policy with an SMS section, including the non-sharing sentence.
6. Terms with a separate block for every SMS program you run.
7. Both dedicated URL fields filled, and each one opened in a private window to confirm what a stranger sees.
8. Every absolute statement in both legal pages re-scoped to the program it belongs to.
9. Sample messages that are the literal strings your code sends, each carrying the business name and the opt-out wording — with content-attribute checkboxes that match them.
10. Consent enforced in code, logged with a timestamp and the method it came from.
11. The whole filing saved as a document before you press submit.

None of this is legal advice, and none of it promises how your own review will go — it is what worked for us, written down while it was fresh. The idea underneath is simple: the registration is not a form you fill in, it is a description of a system that already exists. When the page, the policy, the script and the code all say the same thing, approval is mostly a matter of waiting. When they disagree, the reviewer finds the seam.

If you would rather not learn this the way we did, tell us what you want to send and to whom and we will tell you what the filing needs to look like.