Multi-tenant GHL operations: one console for 20 sub-accounts

There is a number where running a GoHighLevel agency changes character. For most operators it lands somewhere between twelve and twenty sub-accounts. Below it, you know every account. You remember which one has the weird pipeline, which one still has the old intake form wired to the wrong workflow, which one is on a different phone number. Above it, you do not. You open an account, spend the first two minutes remembering what it is, do four minutes of work, and switch.

That is the moment agency work stops being client work and becomes navigation. And the uncomfortable part is that no amount of discipline fixes it, because the cost is structural. GoHighLevel is designed around being inside one sub-account at a time. Everything good about that design, the isolation, the clean tenancy, the fact that a client cannot see another client, is exactly what makes portfolio work expensive.

This post is about what actually has to be true for one console to operate twenty sub-accounts, and where the platform helps versus where you are on your own.

What GHL gives you at the agency level, and where it stops

Agency view is real and it is useful. HighLevel's tabular view for the sub-accounts list puts every sub-account in a single scrollable grid with one-click column ordering, filtering to locate specific accounts, and control over which columns are shown. If your question is "which accounts did I create in March" or "sort these alphabetically," that view answers it in seconds.

Now notice what those columns describe. They describe the account: its name, its creation date, its status. They do not describe what is inside it. The questions that actually cost an agency owner a day are all inside questions:

• Which of my twenty accounts still have a workflow pointing at a pipeline stage that no longer exists?
• Which ones never got the updated consent language on the intake form?
• Which ones have an SMS workflow published while the A2P campaign is still pending?
• Which custom fields exist in the account I onboarded last week but not in the one I onboarded in February, and does the workflow I am about to clone depend on them?

None of those are answerable from the sub-accounts grid. They are answerable one account at a time, by opening it, clicking into the right settings screen, and reading. Twenty accounts, four questions each, and you have burned a morning producing a list you will have to regenerate next month.

The switching tax is not imaginary

I want to be careful here, because it would be easy to invent a statistic. So take this for what it is: general cognitive research, not a measurement of GoHighLevel work. The American Psychological Association's summary of research on task switching reports that psychologist David Meyer estimated the brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone's productive time, and that the cost rises with the complexity of the tasks being switched between.

Nobody has run that study on agency owners toggling sub-accounts. But the mechanism described in that literature is exactly the one you feel at account fifteen: the reload, the reorientation, the interference from the account you just left. And GHL sub-accounts are about as complex and as similar-looking as two tasks can get, which is the worst combination. Similar enough that you mix them up, different enough that mixing them up matters.

This is why "just be organized" is not a strategy. The tax scales with account count and you cannot discipline your way out of a structural cost.

Problem one: credentials do not consolidate

The first thing anyone building portfolio tooling runs into is authentication, and it is worth understanding precisely because half the confusion in this space comes from people expecting a master key that does not exist.

The current mechanism is the Private Integration Token. Per HighLevel's Private Integrations documentation, PIT is the recommended replacement for legacy API keys, new legacy v1 key creation is no longer supported, users can create up to 5 Private Integration Tokens at both the agency level and the location level, and the token string is displayed exactly once at creation with the warning that you will not be able to copy it again later.

Three consequences fall out of that for a twenty-account portfolio:

1. You are holding twenty credentials, not one. A token generated inside a sub-account carries the scopes you granted in that sub-account. Portfolio tooling has to store credentials keyed by location ID and select the right one per call. There is no shortcut around that, only a decision about where the keys live.
2. Onboarding a client has a credential step. Every new sub-account means generating a token, granting the right scopes, and getting it into your store before automation can touch that account. Skip it and the account is invisible to your tooling while looking perfectly healthy in the UI.
3. Copy it once or do it again. The one-time display is not a formality. A lost token is not recoverable, it is replaceable, which means going back into that client's account and reissuing.

Where those keys sit is the security question that should decide your tooling. Twenty client credentials in a vendor's cloud database is a different risk profile from twenty client credentials in a file on your own machine. The first one means a breach at a company you do not control exposes every client you have. If you have ever had to write a client a letter explaining a third-party breach, you already know which side of that trade you want to be on.

Problem two: rate limits, and the good news nobody mentions

Operators assume that fanning out across twenty accounts will hit a wall. For the public v2 API, the opposite is closer to true.

HighLevel's developer API rate limit documentation specifies a burst limit of 100 API requests per 10 seconds for each Marketplace app per resource, and a daily limit of 200,000 API requests per day for each Marketplace app per resource, where a resource means a Location or a Company. Read that carefully: the quota is scoped per account. It is not a pool your whole portfolio draws down.

So adding a sub-account adds headroom rather than consuming it. The constraint that actually bites is per-account velocity, not portfolio size. A sloppy loop that fires two hundred calls at one location in a few seconds will earn a 429 while nineteen other accounts sit idle with full quotas. Sane portfolio tooling therefore paces per account and moves on, rather than treating the whole portfolio as one queue.

That is a genuinely encouraging structural fact. The platform's own limits are not what stands between you and multi-tenant operation. The tooling is.

Problem three: the write that does not know where it is

Here is the failure mode that should scare you more than any of the above, because it is the one that costs a client rather than an afternoon.

Any tool that operates across accounts holds some notion of a current account. That state can drift. It drifts when a session restarts, when a connection drops and reconnects, when a tool updates itself in the background and re-reads a default from configuration. I have watched exactly that happen: a background update reset an active location back to the configured default mid-session, and the next write went somewhere I did not intend. The write itself was fine. The address was wrong.

The defenses are boring and they work:

• Read the current location back from the platform before every write. Not from memory of what you set ten minutes ago. From the system, right now.
• Say the account name out loud in plain language before changing it. Not the location ID, the client's actual business name as you would say it on a call. If your tooling cannot tell you the human name of the account it is about to write to, it is not ready for portfolio work.
• Verify IDs before deploying, not after. A pipeline, stage, custom field, or user ID from account A that does not exist in account B does not throw an error in a GHL workflow. It silently kills the action, and often everything downstream of it. That is the same mechanism that makes invalid IDs kill GHL automations without ever showing a red flag, and cross-account work multiplies your exposure to it because every clone is a chance to carry a foreign ID into a new account.
• Update in place rather than delete and recreate. In production, deleting a workflow to rebuild it severs every connection into it. Cross-account cleanup is where people forget this.

Note how much overlap there is with why snapshots break on the way into a new account. It is the same root cause wearing a different hat. Cross-account operations break because references do not survive the trip, and GHL will not tell you when they fail to.

What a real multi-tenant console has to do

Strip away the marketing and there are five properties. Judge any tool, including ours, against them.

1. One credential store, keyed by location. Register an account once, then address it by name forever. On your machine, not a vendor's.
2. Explicit, readable current-account state. You can ask which account you are in and switch deliberately, and the answer comes from the platform rather than from a cached assumption.
3. Reads that cross accounts. Health summaries, workflow audits, and structure exports that run the same way in every account so the results are comparable.
4. Comparison as a first-class operation. "What does account B have that account A does not" should be a question you ask, not a spreadsheet you assemble by hand.
5. Pricing that does not tax the portfolio. If the tool bills per sub-account, it is charging you for the exact problem it claims to solve. We wrote the full arithmetic on that in the hidden cost of per-sub-account automation fees.

That fifth one is not a pricing preference, it is an operating constraint. Per-account billing changes your behavior: you stop connecting the small accounts, you stop running audits across everything because every extra account is another line item, and you end up back at partial visibility. The whole reason to build a console is to look at all of it. A meter on the count guarantees you will not.

How we run it

GHL Command is the version of this I built because I was living the problem across my own brands and client accounts. It runs from Claude on your own computer. You register each sub-account once, its credential stays in a local file on your machine, and after that you address accounts by name. Switching is a sentence, not five clicks and a page load. Reads run across the portfolio: account health summaries, workflow audits that flag the invalid-ID failures above, structure exports, and direct comparison between two locations. It reaches the workflow builder layer that most integrations cannot touch, so cloning, trigger changes, and branch logic are on the table rather than something you go do by hand afterward.

It is 233 tools across 49 modules, flat $97 a month, every sub-account you manage included, on up to three machines. Not per account. Sign five more clients this quarter and the bill does not move.

It will not make twenty accounts into one account. Nothing will, and honestly you would not want it to, because the isolation is the reason client data stays client data. What it removes is the tax you pay for that isolation: the reloading, the reorienting, and the slow accumulation of things you no longer know about accounts you are responsible for.

Frequently asked questions

Can one Private Integration Token work across all my sub-accounts?
No. A token is generated inside the account you are standing in and carries the scopes granted there. HighLevel documents a limit of 5 Private Integration Tokens at both the agency level and the location level, and the token string is shown only once at creation. Portfolio tooling holds one credential per sub-account, keyed by location ID.

Do GHL API rate limits get worse as I add sub-accounts?
No. HighLevel documents 100 API requests per 10 seconds and 200,000 requests per day for each Marketplace app per resource, and a resource is a Location or a Company. The quota is per account, so adding a client adds capacity rather than consuming a shared pool. What you have to manage is how fast you hit any single account.

Is agency view the same thing as multi-tenant operation?
No. The sub-accounts tabular view gives you sorting, filtering, and selectable columns across a grid of accounts, which is comparison of accounts. Multi-tenant operation means reading and changing what is inside them: workflows, pipelines, custom fields, and forms across twenty locations in one pass.

What is the single biggest risk in cross-account tooling?
Writing to the wrong account. Confirm the active location from the platform immediately before any write, name the account in plain language first, and treat any session that restarted, reconnected, or auto-updated as having an unknown active account until you have checked.