What Your Clinic Website Needs Before A2P Will Approve You

For most of the last two years, the standard advice for getting a clinic's text messaging approved was the same almost everywhere, including on this blog. Put a contact form on your site with a phone field and two consent checkboxes, one for transactional messages and one for promotional ones, and make sure your legal pages say the right things. That pattern passed review on our own accounts and on client accounts many times.

In September 2026 it became the pattern that gets a submission flagged. The registration flow on the platform we build clinic accounts on was replaced. The new default flow generates its own opt-in widget for your website and asks you to confirm that the widget is the only thing on the page collecting text message consent. A contact form with consent checkboxes now makes that confirmation false. We found this out live, partway through a client submission, and rebuilt the site before anything was submitted.

This post covers what a clinic website needs under the current rule. Registration standards change without notice, approval sits with the carriers and The Campaign Registry rather than with any platform or agency, and outcomes vary by account. Read this as our current operating checklist, dated and sourced, not as legal advice.

What Changed, in One Paragraph

Under the old flow you wrote the opt-in description yourself and pointed the reviewer at your own form. Under the new default flow, the platform generates a chat widget for your site that carries its own consent checkboxes and disclosures, and it writes the opt-in description and sample messages for you as read-only fields. Its own documentation says the generated widget includes your business name, a frequency disclosure, a message and data rates notice, and STOP and HELP instructions, and that the disclosure language and checkboxes cannot be edited (HighLevel help center, updated September 2026). That moves the hardest part of the old submission, describing your opt-in correctly, off your plate. What is left for the website is narrower and stricter: give the widget a clean page to live on, and make everything else on the site prove you are the business you registered.

1. A Real Site That Matches Your Registration

The first question a reviewer asks is whether the website belongs to the business on the registration. The platform's own checklist asks that the site be live and publicly accessible, that it clearly represent the registered business with matching business information, and that it show contact information. In practice that means:

• Real pages with real navigation. Home, about, services, contact, privacy policy and terms. A single landing page or a site-builder preview link is a risk we do not take.
• Your legal entity in the footer of every page, spelled exactly as it appears on your IRS paperwork and your brand registration. Your public clinic name can appear everywhere else. If the two differ, describe the clinic as a service of the legal entity. Avoid "dba" and "operated by", which read as an intermediary sending on someone else's behalf.
• Contact details that match what you registered. Displaying your clinic phone number is fine. Collecting a visitor's phone number in a form is the problem, which is the next section.

2. One Opt-In Path, and Only One

This is the rule that changed. The platform's documentation says the chat widget should be the only form on the submitted page collecting text message consent. We apply that to every page of the site, not just the one we submit, for a simple reason: a reviewer can land anywhere, and a second consent path anywhere on the site contradicts the confirmation you signed. Concretely:

• No phone field on any form on the site.
• No text message consent checkbox anywhere on the site.
• No opt-in wording on the registered page, such as a block that says "by providing your phone number you agree to receive texts." Even when that block collects nothing, a reviewer sees a competing opt-in. Delete it rather than rewording it.
• A plain contact form can stay. Name, email and message are fine, with one line saying the form does not sign anyone up for texts and pointing to the chat window instead.

If your clinic collects consent some other legitimate way, such as a paper form at the front desk, the platform still offers a manual registration path for that. It labels the manual path as slower to approve, and the opt-in description becomes yours to write and defend again. For a clinic whose texting starts from its website, the default flow is the shorter road.

3. The Widget Itself: Mixed, Installed Last, Tested Live

Three details decide whether the widget on your site is the widget you registered.

Choose the Mixed use case. Clinics send two kinds of message: appointment confirmations and reminders on one side, occasional offers and event invitations on the other. The Mixed option renders two separate consent checkboxes, one informational and one promotional, and neither is pre-selected (HighLevel help center, updated September 2026). A promotional-only widget does not cover appointment reminders. Unchecked boxes matter on the carrier side too. Twilio's documentation for error 30925 lists a pre-selected consent checkbox, and consent that only appears as acceptance of general terms, among the reasons an opt-in fails to show clear, affirmative consent (Twilio, error 30925).

Install it after the use case is final. On our builds, changing the use case issued a new widget ID. A site still carrying the earlier snippet shows a widget that no longer matches the registration. Settle the use case first, then paste the snippet before the closing body tag on every page, deploy, and check the live pages for the current ID.

Test it on the live site with a real phone. Open the site in a private window, count the consent boxes, and send yourself a message through the widget. A widget that renders is not the same as a widget that works, and a reviewer can try it.

4. Privacy Policy and Terms That Say the Specific Things

The legal pages did not change under the new flow, and they are still checked closer to a string search than a careful reading. The platform's checklist requires both pages to exist. The carrier-side guidance spells out what the privacy policy has to say: Twilio's error 30925 guidance calls for a statement that mobile numbers are not shared with third parties, a message frequency disclosure, and a "message and data rates may apply" disclosure. The checklist we run on both pages for every submission since the change:

Privacy policy:

• A text messaging section with its own heading.
• Opt-in phrased as "if you opt in to receive text messages," not as consent implied by submitting a form.
• Reply STOP to opt out, and reply HELP for help.
• Message frequency may vary. Message and data rates may apply.
• Mobile information will not be sold, rented, or shared with third parties or affiliates for their marketing or promotional purposes.
• Carriers are not liable for delayed or undelivered messages.
• Consent to receive text messages is not a condition of purchasing any service.

Terms of service: the same STOP, HELP, frequency, rates, carrier and consent lines, plus a plain age statement (you must be at least 18 years of age to use this website and our services) and a support contact with both an email address and a phone number.

Link both pages from the footer of every page using clean URLs without a .html ending, and never mark either page noindex. The widget's consent lines point to these pages, so a broken link here is a broken opt-in.

5. Nothing on the Site That Contradicts the Opt-In

Reviewers read the whole site, not only the page you submitted. The language that caused denials before the change still causes them: outcome guarantees, consumer weight claims, income claims, and anything that suggests you text people who never opted in with you, such as reactivating an old list or generating leads. We covered that vocabulary, with replacement wording, in the exact words that get your A2P campaign denied. That post was written under the old flow, so its advice on building consent checkboxes into your own form no longer applies. Its language table still does.

The about page deserves its own pass. Bios tend to collect phrases like "measurable results" and "unmatched expertise" that nobody reviewing your registration can verify. Rewrite them to describe what the team actually does.

6. Let the Reviewer In

Bot protection and managed robots rules that block automated visitors will make a correct site look empty to an automated checker. Confirm that the home page, privacy policy and terms load without a challenge screen, clear any cache after your last change, and wait several minutes before running the compliance check so it reads the current page rather than a stored copy.

The Order We Run It In

1. Register the brand with the legal name, EIN and address exactly as they appear on IRS records.
2. Build the site with no phone field, no consent checkbox and no opt-in wording, and with complete privacy and terms pages.
3. Deploy it and confirm every page is publicly reachable.
4. Start the campaign, choose Mixed, and copy the widget snippet.
5. Install the snippet on every page, redeploy, and confirm the live pages carry the current widget ID.
6. Test the widget with a real phone on the live site.
7. Only then tick the website compliance confirmation.
8. Save every field of the submission to a document before you click submit.

That last step is the one clinics skip and regret. A denial notice names a category, not a sentence. Without a copy of exactly what you submitted, you cannot compare the attempt that failed with the attempt that passed, and the next round becomes guesswork.

Why This Belongs at the Front of a Launch

An unapproved campaign cannot send, and a resubmission goes back into a queue nobody can escalate. If an event date assumes confirmations and reminders will be running, registration is a dependency of the event, not a task to run beside it. We put it on day one of the thirty-day runway before a launch event for exactly that reason.

The Practical Takeaway

Under the current rule, your website no longer collects text consent. It hosts the one widget that does, and everything else on it either proves who you are or stays out of the widget's way. If your site was built to the old checkbox pattern and you have not registered yet, rebuild the form before you submit. If an older site of yours was approved under the old flow, do not use it as the model for the next one. The model is the last site that passed under the current flow.