How to Connect Your AI to GoHighLevel Safely

To connect your AI to GoHighLevel, you create a private integration token, choose scopes, and point an MCP client at HighLevel’s server. That part takes about ten minutes. The part nobody walks you through is the part that matters: where that token lives afterward, what it is allowed to do, and what happens the first time your AI does something you did not intend.

This is the GoHighLevel counterpart to connecting Claude to a Salesforce org. Same shape, different plumbing — and a different ceiling, which is the honest part most guides leave out.

Connecting your AI to GoHighLevel means two different jobs

Before you touch a settings page, separate two things that get sold as one.

The first job is operating your account: look up a contact, send a message, move an opportunity, pull a transaction. Your AI is using GoHighLevel the way a very fast VA would use it.

The second job is building: a custom object your business needs and GHL doesn’t ship, an integration between GHL and the system your operations actually run on, a feature that doesn’t exist in the workflow builder. That’s custom development on top of GoHighLevel, and it is a different problem with different requirements.

The official connection covers the first job well. It does not cover the second. Knowing which one you’re setting up saves you from being disappointed in the wrong thing.

Step 1: Create a private integration token

HighLevel’s private integrations are the current path for a custom client. Per HighLevel’s own documentation, they let you “build powerful custom integrations between your HighLevel account and any other third-party app,” and the flow is four steps: click Create new Integration, give it a name and description, select the scopes it needs, and copy the generated token.

Three details from that page are worth internalizing:

The token is shown once. Copy it when it appears; the docs note it is not retrievable later. If you lose it, you rotate it.

It’s static. Unlike an OAuth 2.0 access token that refreshes on a cycle, a private integration token is described as “static/fixed” and stays constant until you manually rotate it. Convenient to set up. Also means a leaked token stays useful to whoever has it until you go revoke it — which is an argument about where you store it, not about whether to use it.

It works at both levels. Private integrations are “available for both Agencies and Sub-Accounts.” Agency-level access is broader. For a first connection, go narrower.

Step 2: Pick scopes like you’re hiring, not onboarding

The scope screen is the actual security decision in this whole process, and it’s the one people click through fastest.

HighLevel’s model is granular by design — the docs frame it as the ability to “restrict the scopes/permissions that a developer can access on your account.” Treat your AI as that developer. It is a capable contractor on day one, not a partner with a master key.

A rule that has never cost me anything: start read-only. Grant read scopes for the objects you actually want to ask questions about, connect, verify the plumbing works, and live with it for a few days. Add write scopes one object at a time, when you have a specific task that needs them.

This is the same least-privilege logic behind asking hard questions before letting an AI touch your CRM. Every scope you skip is a category of mistake that becomes impossible rather than merely recoverable.

Step 3: Point your AI at the MCP endpoint

HighLevel publishes an MCP server, which is what lets a general-purpose AI client discover and call HighLevel tools without anyone writing a custom wrapper. The help article describes it as a bridge that lets an AI client “discover available tools, query data, and perform approved actions.”

The connection details:

Endpoint: https://services.leadconnectorhq.com/mcp/
Auth header: Authorization: Bearer <your-private-integration-token>
Location header: locationId, set to the sub-account you’re connecting

That’s the whole handshake. Your MCP client — Claude or anything else that speaks the protocol — then sees the tool catalog and can call it.

One current limitation to plan around: the documentation states that OAuth support is “planned for a future release,” and private integration tokens are what the MCP server accepts today. That is fine for a single operator or a small team. It also means the token is the identity, which brings us to the step everyone skips.

Step 4: Prove the connection with a read before you allow a write

Do not let the first thing your AI does be a change.

Ask it to fetch one contact by ID. Ask it to list your pipelines. Ask it to pull the custom fields defined on the location. These are boring on purpose: each one confirms a different part of the chain — token valid, scope granted, location correct, tool catalog reachable — and none of them can damage anything if you got a header wrong.

A read that returns the wrong data is a much better first lesson than a write that lands on the wrong sub-account. If you manage several accounts, that locationId header is the single most likely thing to be wrong, and a read is the cheapest way to catch it.

Step 5: Decide where the token lives — this is the real setup

Here is where most “connect AI to GoHighLevel” guides stop, and where the actual risk begins.

The default is that the token ends up in a config file on somebody’s laptop. It works immediately, which is exactly why it’s so common. Then: the laptop sleeps mid-task, the token gets copied into a second machine when a teammate needs access, nobody rotates it when that teammate leaves, and there is no single place that records what was done with it.

The alternative is that the connection runs somewhere that isn’t a personal machine — a server your team addresses, holding the credential, running the sessions, keeping one record of what happened. I’ve argued the general case for giving your AI its own server rather than a laptop; GoHighLevel’s static token model makes the argument sharper, because a token that never expires on its own really does not belong in a folder that syncs to a cloud drive.

If two people will ever use this, add one more rule: one write path at a time. Unlimited reads are harmless in parallel. Concurrent writes from two AI sessions against the same account are how you get changes nobody can attribute — which is the whole reason for a single write key passed like a baton.

Where the official MCP server stops

Now the honest part.

The HighLevel MCP server is a fixed catalog of tools. The help documentation lists tools across contacts, conversations, calendars, opportunities, payments, locations, and posting surfaces like blogs, emails and social. HighLevel’s own launch announcement, from July 2025, framed the server as “the automation adapter between AI agents and the HighLevel ecosystem” — letting agents “schedule appointments, follow up with leads, update CRM records, manage pipeline stages and even pull transaction data.” The catalog has grown since; the announcement mentioned 21 tools at launch.

Read that list again and notice what kind of verb it is. Every one of them is an operation. Not one of them changes what your GoHighLevel account can do.

That’s not a knock on it. If what you want is an AI that handles follow-up, the setup above is free and genuinely good, and you should go do it this afternoon.

But watch what happens next, because it happens to almost everyone: within a few weeks a client asks for something GHL doesn’t do. A field that should exist and doesn’t. An integration between GHL and the system your operations actually run on. A piece of logic the workflow builder can’t express. And you go looking for the tool that does it, and there isn’t one — because a tool catalog can’t reach past the operations it was built for, no matter how many tools land in it. That’s the ceiling I described for REI operators running on GoHighLevel, and it’s a ceiling of category, not of capability.

What building on GoHighLevel needs that a token doesn’t provide

Custom development means your AI writes and deploys something. The moment that’s true, four requirements appear that a private integration token does not answer:

A place to run. Build sessions are long, stateful, and shouldn’t die because a laptop closed.

Credential custody. The static token, plus every other key the build touches, held somewhere with one owner rather than distributed by copy-paste.

A record. Not “what does the account look like now,” but what changed, when, at whose request. Operations are self-evident in the UI; a build is not.

A way back. A snapshot taken before a change goes in, so a wrong build is an inconvenience rather than an incident.

That’s the layer Sentinel exists to be. Each client gets a dedicated VM their AI connects to over MCP with key-based auth — unlimited read keys, one write key at a time — every action logged, and a snapshot taken before deploys.

Let me be precise about what that does and does not mean, because the industry is sloppy here: Sentinel does not prevent your AI from making a change you’ll regret. It is not a set of guardrails that refuses. It makes what happened visible and what went wrong recoverable. That’s a deliberate trade — freedom plus visibility, rather than restriction — and if you want a system that blocks things, this is the wrong one.

What this looks like when the setup is handled for you

Everything above is the do-it-yourself path, and I wrote it out in full because you should know what the work actually is before deciding whether you want to own it.

Here’s the other version. With a Sentinel, the environment is provisioned automatically — your own VM, static IP, DNS and SSL, and your own instance URL, with no manual steps. What arrives is a plugin file built for your setup. You save it, drag it into Cowork, and click Install. There’s no token to hand-generate, no header to assemble, no config file whose location becomes a security decision six months later.

The first things you’re asked to run are deliberately boring, for exactly the reason I told you to start with reads: “Check my VM connection.” “What’s running on my server?” “Build me a simple test page and put it live” — which returns a real URL on your own instance in about a minute. That last one is the connection proof, and it’s a great deal more convincing than a contact record coming back.

Connecting GoHighLevel is then a prompt rather than a project. You hand your AI the API key and location ID and ask it to store them on your VM and confirm it can list contacts. You still own the credentials — Sentinel is a hub, not a middleman holding your keys — but they live on a server with one owner instead of in a folder that syncs to somebody’s laptop, and everything done with them lands in a log you can read in your dashboard.

And the first real build isn’t something you do alone. Onboarding includes me helping you ship it, which in practice is the difference between an AI that’s connected and an AI that’s actually used.

A safe rollout order

If you’re doing this yourself, in order:

Create a private integration on a single sub-account, not at agency level.
Grant read scopes only.
Connect your MCP client with the endpoint, bearer token, and locationId.
Run three read prompts and confirm the data matches what you see in the UI.
Decide where the token lives before you add a write scope. Not after.
Add write scopes for one object, for one specific task.
If more than one person will use this, establish the single-write-path rule before the second person connects.

Steps 1 through 4 take an afternoon. Step 5 is the one that determines whether this is a tool your agency runs on or an incident waiting for a quiet Friday.

The takeaway

Connecting your AI to GoHighLevel is genuinely easy now, and that ease is doing something sneaky: it makes a credential-custody decision feel like a settings task. Scope it narrow, prove it with reads, and put the token somewhere that isn’t a laptop.

Then answer the real question, which isn’t how do I connect this — it’s what do I want on the other end of the connection. If the answer is operating your account, the free path above is the right one and it starts working today. If the answer is building things GoHighLevel doesn’t ship, you need a server, credential custody, a record, and a way back, and you can either assemble those four yourself or have them handed to you already running.

Sentinel is $500/month per Sentinel, plus a one-time $2,500 onboarding fee on your first one. That gets you the environment provisioned, the plugin built for your setup, and help getting your first build shipped. Set up your Sentinel — onboarding included.