GoHighLevel Sub-Accounts Explained: Structure, Costs, and Common Mistakes

A GoHighLevel sub-account is a self-contained workspace inside an agency’s main GoHighLevel account, with its own contacts, pipelines, phone number, and automations, isolated from every other sub-account. The standard structure for an agency serving multiple clients is one sub-account per client, cloned from a shared snapshot but then run independently. Get the isolation boundary wrong, by sharing an asset that should stay separate, and the mistake tends to surface as a client’s campaign behaving strangely for reasons nobody in the agency can immediately explain.

Why does each client need its own sub-account, not a shared workspace?

GoHighLevel’s sub-account is the account boundary, not a tag or a folder inside one shared workspace. A client’s contacts, conversations, calendars, pipelines, and automations all live inside their sub-account, and nothing there is visible to another sub-account unless the agency deliberately connects them. This is the structural decision that everything else in this guide sits on top of: one sub-account per client is the default, and departures from that default should be intentional, not accidental.

The practical reason this matters is data separation. A client should never be able to see another client’s contacts, and an automation built for one client’s sales process shouldn’t fire for a different client’s leads. Sub-account isolation is what makes that guarantee hold. Agencies that skip this, usually by trying to run several small clients out of one sub-account with tags to separate them, run into exactly the problem sub-accounts exist to prevent: one client’s data mixed into another’s view. GoHighLevel for Agencies: The Complete Setup Guide covers the full account architecture this sits inside.

New sub-accounts are usually populated from a snapshot rather than built from scratch each time. A snapshot is a template of pipelines, workflows, and settings that gets cloned into the new sub-account as a starting point. That’s efficient, but it’s also where the next mistake tends to creep in: treating the sub-account as still connected to the snapshot, or to other sub-accounts, after the clone is done.

What’s the most common structural mistake in a multi-client setup?

The single most common mistake in a multi-client GoHighLevel setup is sharing an asset, a template, a custom value, or a phone number, across sub-accounts that should each have their own. It happens gradually: an agency clones a snapshot for a new client, reuses a phone number “temporarily” instead of provisioning a new one, or points two sub-accounts at the same custom value because it’s faster than setting it up twice. Each shortcut works fine in isolation, right up until a change made for one client quietly changes behavior for another.

Custom values are a typical example. If a business-name or booking-link custom value gets set at a level that’s shared rather than sub-account-specific, updating it for Client A can silently update the same field showing up in Client B’s automated texts or emails. Nobody notices until a client asks why their outbound message is referencing the wrong business name, and by then the agency is debugging a problem that traces back to a setup decision made months earlier.

The failure mode with shared assets isn’t a crash or an error message, it’s silent behavior drift that only surfaces when a client notices something looks wrong, which means it often goes undetected far longer than a hard failure would.

Phone numbers deserve their own callout because the failure mode is worse than a mislabeled text. A shared number breaks call routing and caller-ID attribution outright: inbound calls land in the wrong sub-account’s conversation thread, and there’s no clean way to tell which client’s campaign generated a given call or reply. Each sub-account should have its own dedicated number, provisioned specifically for that client, full stop. If an existing setup already has a shared number that clients depend on, correcting it isn’t a quick settings toggle. It’s a structural rebuild: provisioning new isolated numbers, migrating each client’s routing and campaigns onto them, and testing that nothing breaks for the client who was relying on the shared version in the meantime.

Why do usage-based costs run through a separate wallet, and how can they surprise you?

GoHighLevel’s flat monthly subscription covers the platform itself, but calling, texting, and email sending are billed separately through a usage-based wallet tied to each sub-account. That distinction matters because it’s easy to budget for the subscription and forget the wallet entirely, right up until a client runs a heavy SMS campaign and the wallet drains faster than expected.

This is a real, recurring pattern for agencies running text-heavy campaigns on behalf of clients: a promotional blast, a review-request sequence, or an appointment-reminder workflow can consume wallet funds quickly, especially at volume. Because each sub-account has its own wallet, one client’s high-usage campaign doesn’t affect another client’s balance, which is good for isolation but means the agency needs to monitor usage per sub-account rather than assuming one aggregate number tells the whole story.

The practical fix is straightforward: set a wallet balance alert per sub-account, and have a conversation with any client running SMS-heavy campaigns about what usage costs to expect before the campaign launches, not after the wallet hits zero mid-send. Building that expectation into onboarding avoids the awkward conversation where a client asks why their texts stopped going out in the middle of a campaign.

Auto-recharge settings, where a sub-account’s wallet tops itself up automatically once it crosses a low-balance threshold, are worth enabling deliberately rather than leaving at whatever the default is. Auto-recharge off means a campaign can silently stop sending the moment the wallet hits zero, with no warning beyond whatever balance alert was configured; auto-recharge on means the campaign keeps running, but a client who didn’t expect the top-up charge can be caught off guard by an unplanned line item on their invoice. Neither setting is universally correct: it depends on whether the agency would rather have an unexpected pause or an unexpected charge, and that’s a decision worth making explicitly per sub-account rather than accepting whatever the account defaulted to when it was provisioned.

How should multi-location setups mix shared and isolated assets?

Multi-location businesses, a franchise with several offices or a healthcare group with multiple clinics, don’t fit neatly into either “one shared account” or “fully separate sub-accounts.” The workable structure is usually one sub-account per location, cloned from a common snapshot so branding and base workflows stay consistent, but with the phone number and usage wallet kept isolated to each location.

The logic mirrors the shared-template problem above, applied at the location level instead of the client level. A shared snapshot template makes sense because most locations run the same core process, and updating the template centrally is efficient. But a shared phone number across locations recreates the exact routing and attribution problem described earlier, and a shared usage wallet means one location’s high call volume can eat into budget meant for another. Keep the number and the wallet local to the location, and share what benefits from consistency — the pipeline structure, the review-request workflow, the base automation logic. GoHighLevel Snapshots Explained covers how to build that shared template so it actually adapts cleanly to each location instead of just being cloned as-is.

One asset that can reasonably live above the individual location is top-level reporting. An owner overseeing five locations usually wants a consolidated view of performance across all of them, not five separate dashboards to check individually, even though each location’s sub-account stays functionally isolated underneath that view.

How does central reporting sit on top of isolated sub-accounts?

For an agency owner managing multiple client sub-accounts, or a multi-location owner managing several location sub-accounts, GoHighLevel’s agency-level dashboard aggregates key metrics, contact counts, pipeline value, campaign activity, across every sub-account under the account. That gives account-level visibility without requiring anyone to open each sub-account individually just to get a pulse check.

It’s worth being precise about what this reporting layer is and isn’t. It’s a summary view built on top of isolated sub-accounts, not a merge of the underlying data. Detailed reporting, individual conversation history, and granular automation performance still live inside each sub-account. An agency owner checking the aggregate dashboard and noticing a dip in overall pipeline value still needs to drop into the specific sub-account to find out which client’s numbers moved and why. Treat the top-level view as a monitoring tool that tells you where to look, not a substitute for the per-client detail underneath it.

How many sub-accounts can one agency account actually hold?

The sub-account cap depends entirely on plan tier, and it’s one of the more consequential differences between GoHighLevel’s Starter plan and the two tiers above it. Per GoHighLevel’s own pricing page, Starter at $97/mo limits an agency to 3 sub-accounts total, which makes it a reasonable fit for a single business running its own account, or a very small operation testing the platform, but not a viable base for an agency planning to onboard clients past that number.

Unlimited at $297/mo and Agency Pro at $497/mo both remove the sub-account cap entirely. There’s no published ceiling on how many sub-accounts an agency can provision once it’s on either of those tiers, which is the structural reason most agencies serious about scaling past a handful of clients move off Starter early rather than waiting until they hit the 3-account wall mid-onboarding. It’s worth noting that removing the sub-account cap doesn’t remove usage-based costs: each new sub-account still draws its own Agency Wallet balance for SMS, voice and email, so unlimited sub-accounts means unlimited account slots, not unlimited spend. The GoHighLevel pricing guide breaks down exactly how those per-unit usage rates work alongside the flat plan fee.

What API rate limits should agencies managing many sub-accounts plan around?

Clicking through the dashboard one sub-account at a time rarely runs into a rate limit. Building custom tooling, a bulk reporting dashboard, an automated snapshot-push script, an integration that syncs data across every sub-account, is where GoHighLevel’s published API limits start to matter, and they’re worth knowing before an agency commits developer time to that kind of build.

Per HighLevel’s API rate limits documentation, standard API keys are capped at 500 requests per 10 seconds per sub-account, with some rate-sensitive endpoints, conversations and reporting among them, carrying lower limits than that baseline. Marketplace OAuth apps, the category built for third-party integrations sold across many agencies rather than internal tooling, are capped separately at 200,000 requests per day and 100 requests per 10 seconds per sub-account. Because these limits are scoped per sub-account rather than pooled across an agency’s whole portfolio, an agency with 40 sub-accounts isn’t dividing one shared allowance 40 ways, each sub-account gets its own budget, but a script that loops through all 40 sequentially without pacing logic can still trip a limit on whichever sub-account it’s hitting at that moment.

The practical takeaway for an agency scoping custom development against its sub-account structure: budget for retry and pacing logic from the start if the tool will touch more than a handful of sub-accounts in a single run, rather than treating rate limits as something to patch after the first 429 error shows up in production. Agencies without in-house developer capacity for that layer are usually better served either using GoHighLevel’s built-in bulk tools, which handle pacing internally, or bringing in a developer who’s already built against these specific limits rather than learning them live against client accounts.

How do you offboard or transfer a sub-account without losing data?

Client relationships end, agencies get acquired, and sub-accounts occasionally need to move between agency accounts, so it’s worth knowing what those processes actually involve before assuming a sub-account can simply be deleted, exported, or handed off the same way you’d export a spreadsheet.

Transferring a sub-account from one agency account to another is an administrative process, not a self-service drag-and-drop action. It’s worth confirming exactly what carries over and what doesn’t before relying on it, particularly phone numbers, connected integrations, and historical usage data, since not every asset attached to a sub-account is guaranteed to move cleanly with it. Agencies going through an acquisition, a partnership dissolution, or simply handing a client’s account back to them directly should treat this as a step to plan and test in advance, not something to figure out under time pressure during the actual transition.

Deleting a sub-account outright is more final. GoHighLevel does not guarantee indefinite data retention after deletion, so any contact records, conversation history, or reporting data an agency or a departing client wants preserved needs to be exported or archived before the delete happens, not after. This matters most for agencies operating under contracts that require data retention for a certain period post-cancellation, or clients who simply want their contact list back when they leave. Building a short offboarding checklist, export contacts, export conversation history if needed, confirm the phone number’s disposition, then delete, turns this from a one-off scramble into a repeatable process that protects both the agency and the departing client.

What’s a workable sub-account naming and organization convention at scale?

Once an agency is running more than a handful of sub-accounts, the dashboard’s default sub-account list stops being self-explanatory, and a consistent naming convention becomes the difference between finding the right account in seconds and scrolling through a list trying to remember which sub-account belongs to which client or location.

A convention that tends to hold up at scale combines a few consistent elements: the client or franchise name, a location identifier for multi-location accounts, and sometimes a status tag, active, onboarding, paused, so the sub-account list itself communicates account state without anyone needing to open each one to check. For a franchise with numbered locations, something like “Acme Home Services — Location 07 — Active” is more useful at a glance than “Acme 07,” even though both are technically searchable. The extra clarity matters more the larger the sub-account count grows, since an agency with 60 sub-accounts is navigating that list under real time pressure, mid-support-call, not browsing it casually.

This is a small operational detail compared to the isolation and cost questions covered earlier in this guide, but it compounds. An agency that establishes a naming convention on day one avoids the alternative, a mixed, inconsistent sub-account list that gets progressively harder to navigate as the client base grows, and that eventually requires a cleanup project just to make the dashboard usable again. It costs nothing to set the convention early and consistently apply it to every new sub-account from the start.

What does it cost to set up correctly?

Setup cost tracks the shape of the account more than the number of contacts involved. A single-business GoHighLevel setup, one sub-account, one snapshot, standard automations, typically runs $500-$4,000. A white-label SaaS build, where an agency resells GoHighLevel under its own brand to multiple client sub-accounts, runs $4,000-$10,000 given the added work of white-labeling, snapshot standardization, and onboarding flow for new clients. Multi-location setups, with the shared-snapshot-but-isolated-number-and-wallet structure described above, run $4,000-$12,000 depending on location count and how much reporting consolidation the owner wants at the top level. See pricing for how a specific setup gets scoped into one of those tiers.

Where a given build lands in those ranges depends mostly on how many sub-accounts need to be provisioned, how much of the automation can be cloned cleanly from a snapshot versus rebuilt per client, and whether existing sub-accounts already have shared assets that need to be untangled into isolated ones. That last scenario, correcting a setup where phone numbers or templates were shared when they shouldn’t have been, is the one most likely to push toward the higher end of a range, since it’s rebuild work layered on top of the initial build rather than a clean setup from scratch. GoHighLevel implementation services covers what that audit-first engagement looks like.

It’s worth being specific about what actually drives a project toward the top or bottom of each range, since “it depends” isn’t a useful answer on its own. A single-business build near the $500 floor usually means one sub-account, one moderately adapted snapshot, and standard automations with no custom integrations. A single-business build near the $4,000 ceiling usually means custom API integrations to a booking system or a billing platform, several non-standard automations built from scratch rather than adapted from a snapshot, and a data migration from a previous CRM. The same logic scales up through the white-label and multi-location tiers: sub-account count sets the floor, and integration complexity, migration scope, and how much genuinely custom automation work is involved set how far above that floor the actual quote lands.

Getting the sub-account structure right at the start, one sub-account per client or location, isolated phone numbers and wallets, a shared snapshot used deliberately rather than left half-connected, avoids the slower and more expensive path of discovering the shared-asset problem after a client has already noticed something was off.