Private Integration Tokens in GoHighLevel: scopes, rotation and who should hold them

Every integration you connect to a GoHighLevel account through a Private Integration is holding a key. Not a session that times out at the end of the day. A key. It works until somebody rotates it or deletes it, and in most agencies nobody has written down who holds which one.

That was tolerable when an agency had two integrations and a Zapier account. It is not tolerable now that AI agents, reporting tools, call trackers and custom scripts all want their own access, often in every sub-account you manage. Each one is a Private Integration Token, usually shortened to PIT, and each one is a door into a client's contacts and conversations.

This post is the policy I use for them: what a PIT actually is, how scopes and rotation work according to HighLevel's own documentation, and the simple rules for who in an agency should create, hold and retire them.

What a Private Integration Token is

A Private Integration is HighLevel's way of letting you call its API for your own account without building and publishing a marketplace app. You create the integration in settings, choose what it is allowed to touch, and HighLevel hands you a token. HighLevel's support article on private integrations positions them as the replacement for the old v1 API keys, which gave unrestricted access and can no longer be created.

The developer documentation for the Private Integrations token spells out the property that matters most for an operator. These are static tokens. A normal OAuth access token expires daily and has to be refreshed. A PIT does not refresh and does not expire unless you rotate it from the interface. You send it as a Bearer token in the Authorization header, with a Version header, and it acts with whatever scopes you gave it.

Two more facts from those pages shape everything below. The token is shown once, at creation, and you cannot retrieve it later. And Private Integrations exist at two levels: the agency, and each individual sub-account. HighLevel's current help article puts the limit at 20 integrations at the agency level and 20 at each location.

Agency token or sub-account token

The first decision is where the token lives, and the right default is the narrowest level that does the job.

An agency-level token is for agency-level work: reading the list of sub-accounts, looking up a location's details, creating new sub-accounts. HighLevel's developer docs show agency tokens being used against the sub-account endpoints for exactly that kind of task. Notably, for marketplace apps, an agency OAuth token cannot call sub-account endpoints directly at all; it has to be exchanged for a location-level token through the Get Location Access Token endpoint first.

A sub-account token is for work inside one client's account: contacts, conversations, opportunities, calendars, workflows. HighLevel's own guide to its MCP server has you open the specific sub-account, create the Private Integration there, and send that token together with the location ID on every request. In our operating experience, that is also the pattern that works reliably for anything that reads or writes client data: one token per sub-account, created inside that sub-account.

The operational payoff is containment. If one client leaves, or one integration misbehaves, you delete or rotate a single sub-account token and no other client is affected. An agency-wide key used for everything turns every incident into a portfolio-wide incident.

Scopes: the fewest that work

When you create the integration you pick scopes, which are the specific areas the token may read or edit. HighLevel's guidance on both its help article and its developer page is the same short sentence: select only the required scopes. The MCP guide adds a point worth repeating to every team member. Read and edit scopes are listed separately, so write access is a deliberate choice, and HighLevel recommends granting edit access only when the integration genuinely has to create or update data.

A practical way to apply it:

• Reporting and dashboards: view scopes only. A tool that draws charts has no reason to edit a contact.
• Lead intake from an outside form or call tracker: contact edit, plus whatever it tags or moves. Not conversations, not workflows.
• A builder or operator tool: broad scopes, because it creates pipelines, fields, calendars and workflows. That is a legitimate need, and it is exactly the case where the token should be dedicated, named for that one tool, and on a rotation schedule.

One correction worth making in public, because it was in our own setup notes. We previously told members that a Private Integration's scopes are locked at creation. HighLevel's current documentation says otherwise: you can edit the name, description and scopes at any time from the integration's three-dot menu, editing does not generate a new token, and the existing token keeps working. If you were rebuilding integrations just to add a scope, check the current article first.

Shown once means stored once, properly

Because the token cannot be retrieved after creation, the moment you click Create is the only moment you control where it goes. That moment is where most leaks start: pasted into a team chat to hand off, dropped into a shared document, left in a screenshot for a support ticket.

HighLevel's MCP guide lists the places a token should never appear: public repositories, screenshots, shared prompts and client-side code. To that I would add any chat message, any email, and any spreadsheet. The rule I use is boring and it works. The token goes straight from the HighLevel dialog into a password manager or secret store, under a name that matches the integration name in HighLevel. Nobody pastes it anywhere else. If somebody needs it, they read it from the vault, and the vault records that they did.

Rotation: the two buttons and when to press each

HighLevel recommends rotating PITs every 90 days and gives you two ways to do it, documented on the developer page.

Rotate and expire later issues a new token and keeps the old one working for a 7-day window. During that window you can cancel the rotation or expire the old token immediately. This is the routine option. You rotate, update the new token wherever it is used, confirm the integration still works, and either let the window close or expire the old token yourself once you have checked.

Rotate and expire now invalidates the old token at once. This is the option for a token you believe has leaked, or for an integration belonging to someone who has just left. Expect whatever was using it to break until you install the new value, and accept that cost, because the alternative is a working key in the wrong hands.

Either way, the new token is shown once. Rotation is the moment people most often lose a token, because they are moving fast and treat the dialog as routine. Copy it into the vault before you close anything.

Who should hold them

Here is the part most agencies have never decided. By default, HighLevel lets every agency admin create and manage Private Integrations. The help article notes you can restrict that per admin under Settings, Team, the admin's Roles and Permissions, separately for agency integrations and sub-account integrations.

The policy that holds up:

• One or two named token owners. They create integrations, store tokens, rotate them and delete them. Other admins have the permission switched off. Fewer people with the ability to mint keys means fewer keys nobody remembers making.
• One integration per tool per sub-account. Never one token shared by three tools. If you rotate a shared token, you break three things; if one tool leaks it, you cannot tell which.
• Names that answer "what is this?" Tool name, owner initials and creation month. The day you are auditing an account at speed, a token called "test" or "zap 2" is the one you cannot safely delete.
• A register. A simple list per sub-account: integration name, purpose, scopes, owner, created, last rotated. When a staff member leaves, you sort by owner and rotate everything they touched.
• Clients do not hold your tokens. If a client wants their own integration, they create it in their own sub-account and own it. Your agency's operating tokens stay with your agency.

That register is also what makes inherited accounts survivable. When you take over a sub-account from another agency, the integrations they created are still there and you cannot see the token values. We covered that pass in auditing a sub-account you inherited: anything you cannot identify and account for, rotate or delete.

Retiring a token

Deleting is the step everyone forgets, because nothing prompts it. HighLevel lets you delete an integration from the three-dot menu in Private Integrations. Do it on three occasions: when a tool is no longer used, when a client offboards, and at every quarterly review for anything without a named owner in your register. An unused token with edit scopes is pure risk and no benefit.

Where GHL Command fits

GHL Command is a builder and operator tool, so it sits in the third bucket above: it needs broad scopes because it creates the pipelines, fields, calendars and workflows you ask for. That is exactly why it is set up the way this post recommends. Each sub-account gets its own dedicated Private Integration, named for GHL Command, so you can rotate or delete one client's access without touching the others. Agency-level work, like creating a new sub-account from a snapshot, uses a separate agency token.

The tokens live on your machine, not on our servers. GHL Command runs from Claude on your own computer, and it is the same reasoning behind running a whole portfolio from one console: one operator view across every sub-account, with each account's credentials kept separate underneath it.

Flat $97/mo, every sub-account you manage included, never billed per account.

Frequently asked questions

Does a Private Integration Token expire?
Not on its own. HighLevel describes PITs as static tokens that do not refresh automatically unless you rotate them in the interface. A token nobody rotated is still valid, which is why HighLevel recommends rotating every 90 days.

Can I edit the scopes on an existing integration?
According to HighLevel's current documentation, yes. Name, description and scopes are editable from the three-dot menu, no new token is generated, and the existing token keeps working. Older guidance, including some of our own notes, said otherwise.

What happens when I rotate a token?
Rotate and expire later keeps the old and new tokens working together for 7 days, with options to cancel or expire early. Rotate and expire now kills the old token immediately, for suspected leaks or departing staff. The new token is shown once either way.

Agency-level or sub-account-level token?
The narrowest level that does the job. Agency tokens for agency work such as listing or creating sub-accounts; a sub-account's own token for its contacts, conversations and workflows. HighLevel's MCP server guide uses the sub-account token plus the location ID.

Who should be allowed to create Private Integrations?
One or two named owners. All agency admins can by default; HighLevel lets you restrict each admin under Roles and Permissions, separately for agency and sub-account integrations.