Why Your AI Can't Read Conversations in a HIPAA GoHighLevel Sub-Account

The 401 nobody documents

The complaint that started this was an agency owner's, and it was reasonable: "We turned on HIPAA for the Medicare sub-account and the follow-up bot got dumber." The bot's vendor hadn't changed anything. The prompts hadn't changed. The model hadn't changed. The only thing that changed was a toggle in GoHighLevel's Advanced Settings that the owner had paid $297 a month to be allowed to flip⁴.

We suspected the API, because that is the only door an outside tool uses, and because HighLevel's HIPAA module is described entirely in terms of what it does to stored data: AES-256 encryption with key rotation, enforced MFA, audit logging, role-based access, and a Business Associate Agreement signed in-app⁴⁵. There is no line in that material about what a connected application can and cannot fetch. So we tested it, the way we test everything on this site: two accounts, one request, and the raw responses side by side.

What we tested, and what came back

Both sub-accounts sit in our own agency. One is our marketing location, HIPAA off. The other is a health insurance location with the HIPAA module enabled at the agency level and toggled on for that sub-account, exactly as HighLevel's help article describes⁴. We used a valid integration token for each and called the endpoint HighLevel documents as GET /conversations/:conversationId/messages².

The non-HIPAA account returned the message array. The HIPAA account returned this, verbatim:

{
  "statusCode": 401,
  "error": "Unauthorized",
  "message": "Can not fetch messages from HIPAA compliant account",
  "canonicalCode": "CONVERSATIONS_HIPAA_RESTRICTED",
  "arguments": {}
}

Three details matter. The status is 401, which normally means the credential is bad, but the credential had just succeeded on other calls in the same session. The message names HIPAA explicitly, so this is a deliberate rule, not a scope you forgot to grant. And the canonical code, CONVERSATIONS_HIPAA_RESTRICTED, appears on no HighLevel documentation page we could find, including the API reference for the endpoint that returns it² and the HIPAA compliance article⁴.

What a HIPAA sub-account still serves

The useful half of the test is the map of what didn't break. Against the HIPAA sub-account, with the same token, we read the contact list, the contact's custom fields, its tasks, the pipelines list, and an opportunity search with notes and tasks expanded, notes included. We also called GET /conversations/search, which returned the thread list normally, and each thread carried the lastMessageBody field HighLevel documents as the text of the most recent message³.

Why HighLevel probably does this

HighLevel hasn't explained it, so treat this section as an inference from someone who builds against the API daily rather than a statement of HighLevel's policy. The message body endpoint is the densest PHI surface in the product. A single conversation can carry a client's diagnosis, medications, plan, and Social Security number in the client's own words, and one API loop can page through every conversation in the location. From HIPAA's point of view, a marketplace app or a private integration token is a third party. Closing that one endpoint on HIPAA accounts caps what any connected app can bulk export, while leaving the objects most integrations actually need, contacts, fields, pipelines, calendars, intact.

That is a defensible engineering choice. The problem is not the choice, it's the silence around it. An agency that buys the module on the strength of the help article has no way to know that its follow-up AI, its reporting tool, or its call-review pipeline is about to lose a data source, and the vendor of that tool has no way to know either until a customer complains.

What it means for any conversational AI

Almost every conversational AI tool in the GoHighLevel ecosystem builds memory the same way. A message arrives, a workflow fires, the tool calls the messages endpoint to load the thread, stuffs that history into the prompt, and generates a reply that references last week's call. Remove the endpoint and the tool has exactly two inputs left: whatever the workflow passed in the webhook, and whatever it can read from the objects that still work. If the tool wasn't designed to keep its own memory in those objects, it degrades to last-message-only replies, and it does so quietly.

This is the practical version of a point we made in why AI context is the real differentiator: memory is an architecture decision, not a model feature. A tool whose only memory is "read the CRM's history endpoint" is one platform policy away from amnesia. A tool that writes its own context into the CRM as it goes keeps working, because the objects it writes to are the objects HighLevel keeps open.

The transcript problem on top of it

Calls compound this. HighLevel sells call transcription on LC Phone at $0.024 per recorded minute, on top of $0.0025 per minute for the recording itself and $0.0005 per minute per month to store it⁶. Its Transcript Generated workflow trigger "automatically activates a workflow as soon as HighLevel finishes transcribing a recorded call" and passes "the full transcript, duration, direction, caller location, timestamps, and more" into the workflow, across Voice AI, LC Phone, and IVR calls⁷. Inside the platform, that works. It's a real path for getting a transcript into a note.

The question for an outside system is different: can it pull that transcript through the API on a HIPAA account? Transcripts live under the conversations and messages surface, the same neighborhood as the endpoint that just returned 401. We're not going to assert a result we didn't reproduce this session; we are going to say that if your call-review or coaching tool reads transcripts through the API, test it on the HIPAA sub-account specifically before AEP, not after. The in-platform workflow trigger and the external API read are two different doors, and only one of them is documented as working.

Our own answer sidesteps the door entirely, and it's the same answer we gave in why sales calls never get reviewed: take the audio, not the transcript. Pull the recording into the agency's own vault, transcribe it there, and write the transcript and a structured summary back to the contact as notes, which are an object every producer already reads and the HIPAA API still returns.

The BAA boundary nobody mentions: the model

Here is the part of this that matters more than the 401, because it outlives any API change. HighLevel's HIPAA article lists the objects its BAA covers: "Contacts, Notes, Custom Fields, SMS/MMS, voice recordings, email bodies & attachments, form/survey submissions, calendars, invoices"⁴. The only AI feature it names is Reviews AI⁴. Voice AI and the AI Agent action are not mentioned, and both can now route to external model providers, billed per model⁸. HighLevel's security overview says its subprocessor list lives in its Data Processing Agreement rather than in public documentation⁹.

So the BAA covers the storage layer, including the recordings Voice AI produces. Nothing published says it covers the processing layer, the model that reads PHI to generate the next turn. That is a separate business associate question, and it is the one most agencies never ask because the toggle made them feel covered. We wrote about the same boundary from the outbound side in why a GoHighLevel BAA doesn't make your funnel HIPAA safe. This is the inbound side: the door HighLevel closed protects PHI from third parties, and the AI feature HighLevel opened may be routing PHI to a third party it hasn't named.

How to check your own sub-account

Ten minutes, no developer. Do it on a test contact if you have one.

The DIY workaround, step by step

You can make a conversational AI work on a HIPAA sub-account without us. The pattern is simple to describe and tedious to maintain.

Deliver the newest message by webhook, don't fetch it. Build the inbound-message workflow so the webhook payload carries the message body and the contact ID. Your AI reads what the workflow hands it, not what the API refuses.

Give the AI its own memory in a large-text custom field. Create a contact-level custom field, and have the AI append a dated entry for every message it sends and every inbound it processes. Custom fields are on HighLevel's covered-data list⁴ and read normally on the HIPAA account in our test. Cap the field's length and roll the oldest entries into a note when it fills.

Put structured call context in notes. Use the Transcript Generated trigger to add the transcript as a note⁷, then add a second, short note with the fields your AI actually needs: topic, objection, quoted plan, promised next step, date. Notes came back in our opportunity search on the HIPAA account. Test that the transcript merge field populates your note the way you expect before you rely on it.

Never fill the gap by pasting. If anyone on the team "catches the AI up" by copying a client thread into a general chat tool, you've moved PHI to a vendor with no BAA. 45 CFR 164.514(b)(2) lists the 18 identifiers that have to come out before data counts as de-identified, names and dates and phone numbers among them, and 164.514(c) only allows a re-identification code that is "not derived from or related to information about the individual" and whose mechanism is never disclosed¹⁰. That is the legal shape of what a proper scrub has to do, and it is not something a producer does by hand on a Friday in November.

How we build around it

Ambrose was designed on the assumption that a client's CRM will have sub-accounts at different compliance postures, and that the platform underneath will change what it serves. Four pieces do the work, and the first two are documented publicly.

Per sub-account HIPAA posture. Ambrose's GoHighLevel spoke carries a per sub-account override: "BAA sub-accounts are treated as safe; others route through PHI Gateway"¹¹. One Ambrose tenant can work across an agency's marketing location and its HIPAA location at the same time and apply the right rules to each, rather than treating the agency as one bucket.

The PHI Rail for everything that isn't BAA-covered. The rail checks the destination against a BAA allowlist. If the destination isn't on it, the payload goes to the PHI Gateway, which will "scrub identifiers, get back a payload of typed aliases (PERSON_xxxx, EMAIL_xxxx, …) + a hydration map." The scrubbed payload goes to the model with a system guardrail that says "never invent identifiers," and on the way back the rail "calls phi_rehydrate with the response + the original hydration map" so the real identifiers are spliced back in. The detection chain is "known contacts (vault membership) → regex patterns → Presidio NER → insurance-specific dictionary," and every scrub event is logged with identifier counts, never the values¹². That is 45 CFR 164.514(c) implemented as software: a code not derived from the person, with the mapping held inside the tenant and never disclosed¹⁰.

Memory that never touched the blocked endpoint. In the current build, when a GoHighLevel workflow delivers an inbound message, Ambrose reads the message from the webhook, not from the API. It maintains a per-contact custom field named AI Conversation JSON, a large-text field it creates on first use and appends to with every generated SMS or email entry and a server-side timestamp. That field, plus notes, is the agent's memory of the thread. On the HIPAA sub-account in our test, both objects read normally.

Transcripts from audio, under our own BAA. Ambrose pulls the call recording into the agency's own vault and transcribes it there with Amazon Transcribe, running under our BAA-covered AWS account. Amazon Transcribe and Amazon Bedrock both appear on AWS's HIPAA eligible services list¹³. The transcript and the structured summary come back to the contact as notes. Nothing in that path asks HighLevel's message surface for a transcript, so the 401 is irrelevant to it.

Two honest boundaries. The AI Conversation JSON field and the vault transcription path are how the build works today, confirmed in the product while writing this; the posture override and the PHI Rail are the parts in the public docs linked above. And HighLevel's BAA is HighLevel's: our posture treats a HIPAA-on sub-account as BAA-covered for the GoHighLevel data itself, and handles the model layer ourselves, which is the layer HighLevel's HIPAA article never addresses.

What you actually get

Concretely: a conversational AI on your HIPAA sub-account that references last week's call because it wrote that call down itself, in objects HighLevel keeps open. Call transcripts and summaries in notes without paying per minute for a transcript your outside tools may not be able to read anyway. A single place where the answer to "which system can see which client data" is written down, per sub-account, instead of living in whoever set up the integration last spring. And a model layer whose BAA status is your decision, not a line item you're hoping HighLevel's help article covers.

None of that is a promise about a legal outcome or an audit result. It's an architecture decision about where an AI's memory lives and which vendor's agreement covers it, made before the platform under you changes the rules again.

When this doesn't matter

If the sub-account doesn't have the HIPAA module on, none of the API behavior in this article applies, and a history-reading AI works as advertised. If your HIPAA sub-account's AI only ever needed the newest message, an appointment-reminder responder for example, you've lost nothing. And if your team writes disciplined post-call notes and keeps a context field current by hand, the DIY workaround above is a defensible position for a single office with a small, careful team. The math starts to matter when volume, turnover, or a downline makes "someone keeps the notes current" a plan that fails the first busy week of AEP.

Questions agencies ask