A2P 10DLC registration, and why a perfectly good snapshot sends nothing

Here is a support ticket we see in some form most weeks: the snapshot installed cleanly, the workflows are published, the test contact is in the right stage, the trigger fired, the workflow history shows the SMS step executed — and no text arrived.

Almost always, the workflow is fine. The number is not registered.

What is actually happening

US mobile carriers require application-to-person traffic on standard 10-digit long codes to be registered under the 10DLC framework: a brand (who the business is) and a campaign (what you send and how people opted in).

The important part for anyone building automation is what happens to unregistered traffic. It is rejected at the carrier edge. Not throttled, not deprioritised, not delivered to spam. The message does not reach the handset and the sender sees nothing that looks like a failure inside their own tooling.

This is why it is such a reliable source of confusion. Every layer you can see reports success. The rejection happens at a layer you cannot see.

So before debugging any SMS problem in GoHighLevel, check the campaign status in the Trust Center under phone number settings. If it is not approved, nothing downstream of it matters.

Why this reorders a snapshot launch

A snapshot is mostly SMS. Appointment confirmations, the 24-hour and 1-hour reminders, the 15-minute alert, no-show recovery, review requests, reactivation. Take SMS away and a vertical system loses most of its surface area.

Which makes registration a hard dependency for launch — and the only one whose timeline you do not control. Domain authentication is your work. Custom values are your work. Approval is somebody else’s.

The practical consequence, and it is the single most useful thing in this article: registration starts at signature, in parallel with the build, not as a step near the end. On a multi-account rollout, staggering registrations at the front is the difference between a two-week launch and a six-week one — which is why it is step four in rolling one snapshot across every sub-account rather than a footnote.

What you need before you start

Registration asks for legal, verifiable facts about a real business. Gather them once, per client, at onboarding:

• Legal business name, exactly as registered — not the trading name.
• EIN or equivalent business tax ID, matching that legal name.
• Registered business address, matching the filing.
• Business website, live, on a domain that matches the business.
• A privacy policy and terms, reachable from that website.
• An authorised contact with a business email address on the business domain.
• Use case — what the messages are for.
• Sample messages representative of what will actually send.
• Opt-in evidence — how a customer consents, visible on the site.

Two of those are where snapshot deployments come unstuck. The website is often not live yet when registration is submitted, because the snapshot builds it. And the opt-in evidence is often not there at all, because the form was designed for conversion rather than for compliance.

The rejections we see most

Reviewers are checking that a coherent, real business is asking to send messages people agreed to receive. Nearly every rejection is a break in that chain.

Details that do not match. The legal name on the brand does not match the EIN filing, or the address differs from the registration, or the website’s business name differs from both. Reviewers are matching records, and near enough is not.

A website that does not corroborate. Parked, under construction, or a single landing page with no business identity, no contact details and no policies. If the site does not establish who the business is and what it does, the submission has nothing to stand on.

Missing or invisible opt-in. This is the big one for automation. The submission has to describe how a customer consents to SMS, and the website has to show it. A form with no consent checkbox and no statement about message frequency and rates does not evidence consent.

Sample messages that do not match the use case. Registering a customer-care use case and submitting promotional samples is a mismatch. Send samples that look like what the workflows actually send — including the opt-out language.

No opt-out. Every campaign needs a clear stop mechanism and the messaging needs to honour it.

GoHighLevel surfaces structured rejection reasons in the Trust Center, and eligible reasons can be corrected and resubmitted in place. Some locked fields — the use case, for instance — can require a new campaign instead, which is why it is worth being careful the first time rather than fast.

Fix the snapshot so it registers, not just so it converts

This is the part that belongs in the snapshot rather than the checklist, and building it in once means every subsequent install inherits it.

Consent in every form. An explicit, unticked SMS consent checkbox with its own wording — what they will receive, roughly how often, that rates may apply, and how to stop. Not buried in a terms link.

Policies on the site. The professional website component in every one of our snapshots ships privacy and terms pages, and they are there for exactly this reason rather than as decoration.

Opt-out honoured everywhere. Stop handling belongs in the workflows, not in the hope that the carrier handles it.

A consent field on the contact record. So you can prove when and how somebody opted in, and so sequences can be conditioned on it.

Get those four into the source sub-account and every install afterwards is pre-built for registration. That is the pattern in how to create a GoHighLevel snapshot generally: the things that are the same for every client belong in the snapshot, and the things that are not belong on the reconnection list.

Designing a launch that survives a pending registration

Assume approval might not land before go-live and the launch stops being fragile.

Voice does not need 10DLC. The AI receptionist answers calls, qualifies and books from day one. In most verticals that is the single highest-value component anyway, so a voice-first launch week is not a degraded launch.

Email does not need it either. It needs its own domain authentication, which is your work and can be finished on schedule.

Sequence the switch-on. Bring up voice and email first, then enable SMS steps once the campaign is approved. If the snapshot’s campaigns are switched on in order rather than all at once — which is the rule anyway, per how to install a GoHighLevel snapshot — this costs nothing.

Tell the client the sequence up front. “SMS switches on in week two pending carrier approval” lands fine at signature. The same sentence in week two does not.

Where the per-account work is irreducible

To be blunt about it: no snapshot removes this. Registrations belong to numbers, numbers belong to accounts, and snapshots carry configuration rather than connections. Every sub-account needs its own number and its own registration, every time.

What a well-built snapshot does is make the registration pass — consent captured properly, policies present, samples matching, opt-out honoured — so it is one submission rather than three.

If you would rather the whole account-side layer were set up correctly once, that is agency account setup; if you want the per-client install and its reconnection list handled, that is snapshot installation. Everything in the library ships with the consent capture, policy pages and opt-out handling already built in, and installation is free on everything we sell and A2P registration is explicitly on the work order, so the 12 hours of dedicated support that come with a purchase — to be used within 10 days of it — exist partly to get you through exactly this stage.

Start the registration on the day they sign. Everything else about a snapshot launch is under your control; this is the one thing that is not.