HighLevel platform annex

What this annex covers

This is a Platform annex. It describes HighLevel and nothing else: what its APIs expose to an app, whose personal data that is, how a merchant installs and authorises an app, and what happens to access and data when the app is removed.

It exists so that no other page has to restate it. Every app we publish has its own privacy policy at /legal/apps/, and those policies inherit this annex instead of repeating it. An app policy names the specific permissions that app holds, the records it actually touches, and the retention that applies to it. This annex describes the outer limit: what HighLevel makes available to an app that asks for it.

Read the two together with these rules:

• An app never holds more than this annex describes, and normally holds far less. We ask for the narrowest permission a task needs.
• Where an app's own policy and this annex differ about what that app does, the app's own policy governs.
• This annex is a description, not a contract. It does not change your agreement with HighLevel. See where the platform's policies govern.

For what an Agent actually does on this platform, see the HighLevel platform page.

HighLevel differs from the other five in two ways that change the whole annex. It is multi-tenant: an agency runs many sub-accounts, each belonging to a different business, so there are often three parties in the chain rather than two. And its central data is conversations: SMS, email and messaging threads with real people, which is regulated content rather than catalogue records.

What this platform exposes to an app

The working surface is the HighLevel API v2, reached with credentials bound to a single location, which is what HighLevel calls a sub-account. An app is installed and granted permissions per sub-account through the marketplace, so an agency can add it to one client without touching the rest. Webhooks push events so the agent wakes on a real event rather than polling.

The table below lists the surfaces our HighLevel work uses, taken from the HighLevel platform page.

Access is granted as named permissions when the app is installed on a sub-account. We are not going to write those names from memory:

• {{VERIFY: the exact current scope names HighLevel API v2 uses for contacts, conversations, opportunities, calendars and custom fields, against the HighLevel developer documentation. Never publish a scope name that has not been read off the current reference}}
• {{VERIFY: whether HighLevel distinguishes company-level from location-level tokens and scopes, and which of the resources above can be reached with a company-level token across every sub-account. This is the single most important thing on this page to get right}}
• {{VERIFY: the current webhook event names, whether the three named above are still current, and whether webhook subscriptions are configured per app or per sub-account}}
• {{VERIFY: whether the older HighLevel API v1 is still available, and whether any credential of that generation grants wider access than a v2 token}}

Personal data an app can reach, and whose it is

HighLevel usually has three parties, not two, and confusing them is how data ends up in the wrong place.

• The agency. Often our Client. It runs the HighLevel account and the sub-accounts inside it.
• The agency's client. The business a sub-account belongs to. The contacts and conversations in that sub-account are that business's records, not the agency's, and usually not ours to hold at all.
• The End Customers. The leads and customers of that business. The people whose phone numbers and messages are in the conversations table. They are not our customers and they are not the agency's customers.

For End Customer Data that an Agent reads or writes on your systems, you are the controller and we are the processor. You decide what the Agent does, which systems it reaches, and what it is allowed to write. We act on your documented instructions, which are the scope and configuration we agree with you in writing.

For Service Data, we are the controller.

Where an agency engages us for work on its clients' sub-accounts, the agency needs to be sure it has the right to instruct us in respect of those records. That is a question about the agency's own contracts with its clients, and it is not one this annex can answer. {{TODO: confirm with counsel whether an agency engaging us for work on its clients' sub-accounts makes us a sub-processor of that client, and whether the DPA needs an agency-specific clause}}

Two consequences we design for rather than describe:

• The location boundary is enforced in the tool layer, not in the prompt. An agent is issued credentials for one sub-account and its tools carry that location on every call. A call for another sub-account's records is rejected before it reaches the API, so the request is never built. This is the first thing we put in place, before any capability is added on top of it.
• Conversations are messages, not records. A run trace on a conversation agent contains what a person actually wrote. That is a higher-sensitivity trace than an order record, and it is why trace retention matters more here than on the commerce platforms. Retention is {{TODO: how long run traces and logs are kept. This one matters, traces can contain end-customer data}}.

How an app is installed and authorised, and what you are agreeing to

Our agents are installed as a marketplace app, granted permissions per sub-account. The same agent is rolled out across sub-accounts as separate scoped installs, each with its own permissions. Widening what an agent can do in one sub-account is a decision made for that sub-account, not a change that lands everywhere.

What you are agreeing to when you install:

• The app may reach every record in that sub-account covered by the permissions granted, including the full text of conversations if a messaging permission is granted.
• HighLevel records the app's actions against the sub-account. A field the Agent sets, or a stage it moves an opportunity to, is a real change to your CRM.
• Installing on one sub-account does not install on the others. That is the point of the per-sub-account model and we build to preserve it.
• The send gate is not optional. Nothing goes out over SMS or email until a person clears it. The agent produces a draft on the conversation, a named person sends it, and the run is traced either way. We do not ship a mode that turns this off. That is a build decision, not a legal one, and we are stating it here because it is the control that matters most on this platform.

We build the approval step, the trace and the record of who cleared what. We do not advise you on the messaging rules that apply to you, and we do not certify anything on your behalf. Outbound SMS and email are regulated, you are the sender, and your counsel decides what is lawful. We build to what they tell you.

{{VERIFY: what the HighLevel marketplace install flow shows an agency or sub-account owner today, whether an agency admin can install an app across every sub-account in one action, and whether a sub-account owner is shown the permissions separately}}

{{VERIFY: whether HighLevel operates an app review before an app may be listed in the marketplace, and what it examines in relation to data handling and messaging}}

Uninstall and deletion

An app is uninstalled per sub-account, from that sub-account's settings. Uninstalling from one sub-account does not uninstall it from the others, which is the same boundary working in the other direction.

What we commit to

On uninstall we delete or return the data held for that sub-account within {{TODO: COMMERCIAL TERM. Days after termination within which client data is deleted or returned}}, subject to the retention terms in the data processing addendum. Because a conversation trace holds message content, this is the platform where we would rather hold less for a shorter period, and each app's policy at /legal/apps/ says what it held.

Your own data stays in HighLevel. Uninstalling an app does not delete contacts, conversations or opportunities. Anything an Agent wrote, a field, a tag, a stage change, a drafted message, stays where it is unless you remove it.

What has to be checked

• {{VERIFY: whether HighLevel revokes an app's access and refresh tokens immediately on uninstall from a sub-account, against the HighLevel developer documentation}}
• {{VERIFY: whether HighLevel sends an app-install or app-uninstall webhook, what those events are called today, and whether handling the uninstall event is mandatory for a listed app}}
• {{VERIFY: whether HighLevel requires an app to delete sub-account data after uninstall, within what period, and where that requirement is published}}
• {{VERIFY: what happens to an app's access when an agency deletes an entire sub-account rather than uninstalling the app, and how long HighLevel retains a deleted sub-account's data}}

Does HighLevel have a mandatory compliance mechanism

We do not know, and this is not a page to guess on. Shopify publishes three mandatory compliance webhook topics every app must implement. Assuming HighLevel has an equivalent would be an invention, and assuming it has none would be just as unsupported.

• {{VERIFY: whether HighLevel operates a mandatory data-request or data-deletion callback that a marketplace app must implement, comparable to Shopify's customers/data_request, customers/redact and shop/redact. If no such mechanism exists, say so plainly here}}
• {{VERIFY: whether HighLevel gives a sub-account a built-in way to delete a contact and everything attached to it, including conversation history, and whether an installed app is notified of that deletion}}
• {{VERIFY: how HighLevel handles an opt-out or STOP reply on a contact, whether that state is exposed through the API, and whether an app is required to respect it. An agent that drafts messages must read this state, so it matters operationally as well as legally}}
• {{VERIFY: what the HighLevel marketplace developer agreement requires of an app that receives a data subject request forwarded by a sub-account owner}}

Until those are confirmed: the business that owns the sub-account is the controller and answers a request about its leads and customers. If someone contacts us directly, we pass the request on and support the answer.

Where HighLevel's own policies govern, not ours

• Your agreement with HighLevel. Your use of the platform is governed by your contract with HighLevel, not by anything we publish, including whatever data processing terms HighLevel offers.
• The agency's agreement with its own clients. Where an agency runs sub-accounts for other businesses, the terms between them govern that relationship. We are not a party to it and this annex does not describe it.
• HighLevel as a processor of your CRM data. HighLevel hosts your contacts, conversations and calendars. What HighLevel itself does with them is described by HighLevel. {{VERIFY: the current URL and title of HighLevel's customer-facing privacy and data processing terms before linking to them}}
• Message delivery. SMS and email leave HighLevel through carriers and delivery providers with their own terms and their own retention. That path is outside our control and outside this annex. {{VERIFY: which messaging and telephony providers sit behind HighLevel's SMS and voice features for the regions you send to, since those are processors in your chain, not ours}}
• Messaging compliance. Whether a message may lawfully be sent to a given person is decided by the law that applies to you and the consent you hold. That is your position to take with your counsel. We build the gate and the trace.
• Cookies in the HighLevel dashboard. HighLevel sets its own cookies to keep you signed in and run the dashboard. Those are HighLevel's, under HighLevel's policies. Our cookie policy covers this website only.
• Marketplace terms. If we list an app, the developer agreement applies to us as the developer. That is our obligation, not a term of your agreement with us.

Related documents

• App policies. The per-app privacy policies that inherit this annex. Start there if you want to know what one specific app holds.
• HighLevel agents. What we build on this platform, the API surfaces we use, and where the human approval gate sits.
• All platform annexes: Shopify, Wix, WordPress, Ecwid, BigCommerce.
• Privacy policy. How we handle personal data on this website and in agency work.
• Data processing addendum. The processor terms that apply when an Agent touches End Customer Data on your systems.
• AI and your data. What reaches a model provider, and on what terms.
• Sub-processors. Every third party that may process data on our behalf.
• Security. How credentials for this platform are held.

Changes to this annex

We may update this document. When we do, we change the "Last updated" date and add a row to the version history below. Section anchors are stable and we do not rename them, so a link to a section keeps working.

Platform requirements change on the platform's schedule, not ours. Anything on this page marked {{VERIFY: ...}} has not been confirmed against HighLevel documentation at the time of writing and must not be relied on until it has been. If you find a statement here that no longer matches what HighLevel publishes, tell us at hello@aispeedforce.com and we will correct it and record the change below.

Version history