Creating GoHighLevel sub-accounts in bulk: three mechanisms and when each one is right
Interface, API, or SaaS mode auto-provisioning. What each mechanism can and cannot do, where the real bottleneck sits, and how to roll out fifty accounts without fifty afternoons.
If you have signed a franchise, bought a book of clients, or won a contract that comes with thirty locations, the interface stops being a reasonable tool. Thirty accounts created by hand is thirty opportunities to type a time zone wrong.
There are three mechanisms for creating sub-accounts at volume. They are not interchangeable, and choosing the wrong one is the difference between a fortnight and an afternoon.
Mechanism 1 — the interface, batched properly
Still the right answer up to about ten accounts, provided you batch it rather than doing it one client at a time as they arrive.
The trick is to stop treating account creation as part of onboarding. Do all the creation in one sitting, from one spreadsheet, with the columns already filled: legal name, trading name, address, phone, email, time zone, website. Create every account from the snapshot at creation time so none of them is ever empty. Then configure them in a second pass, and test in a third.
Three passes over ten accounts is materially faster than ten passes over one account, because you stop context-switching. This is the same batching argument as onboarding ten clients in a month, applied to the narrow question of creation.
Limit: your typing speed, and the fact that nobody concentrates for the fiftieth identical form.
Mechanism 2 — the API
GoHighLevel’s v2 API exposes sub-account creation — still named location in the endpoint, because that was the original term. You authenticate at agency level, POST the business details, and get back an account and its ID.
What this buys you:
- Creation from a source of truth. Your spreadsheet, CRM or client database becomes the input, and the account is created from data that was already checked.
- The ID captured automatically. Every account’s identifier lands back in your own records without anyone copying it out of a URL. This alone justifies the work at scale, for the reasons in what a sub-account actually is.
- Repeatability. Run it again for the next batch. The thirty-first account is created the same way as the first.
What it does not buy you:
- It does not configure the account. Creation is one call. Time zone, phone provisioning, domain authentication, compliance registration and integrations are separate concerns, some of which have no API at all.
- It does not remove the credential work. This is the fixed cost described in what a sub-account costs, and it is stubbornly manual.
Practical notes if you build this: agency-level API access sits on the higher plans, rate limits are real so throttle your loop, log every response including failures, and write the returned account ID straight into your own record before you do anything else with it. An orphaned account you created and cannot identify is a genuinely annoying thing to clean up.
Mechanism 3 — SaaS mode auto-provisioning
The customer creates the account, not you. They subscribe to a plan you defined, the platform provisions a sub-account and loads your snapshot into it automatically, and usage rebilling starts at whatever markup you set.
This is the only mechanism where account creation is genuinely free of your time, and it is the right answer when you are selling software rather than delivering service. It also raises the bar on the snapshot dramatically — nobody is going to configure the account afterwards, so the snapshot has to work with empty custom values and no human. That trade-off is the subject of SaaS mode snapshots.
Limit: it requires the plan tier that includes SaaS mode, and it only fits self-serve commercial models.
Choosing between them
| Situation | Mechanism |
|---|---|
| Under ten accounts, done-for-you delivery | Interface, batched |
| A portfolio migration with a client list you already hold | API |
| Ongoing self-serve signups | SaaS mode |
| A franchise rollout with per-location data | API, from the franchise’s own data |
| One new client this month | Interface — automation is not free either |
The honest version: most agencies asking “how do I bulk create sub-accounts?” do not have a creation problem. They have a configuration problem that presents as a creation problem, because creation is the visible part.
Where the bottleneck actually is
Creation is a minute per account by hand and a second per account by API. Configuration is 90 minutes per account either way, because it is credential work: numbers, domains, DNS, compliance, integrations, payment processors. None of that is meaningfully automatable, and none of it is carried in a snapshot.
So the real levers on a fifty-account rollout are:
- Parallelise the waiting. Compliance registration and DNS propagation are wall-clock time, not work time. Submit all fifty registrations on day one and the queue drains while you build.
- Standardise the build. One kit, loaded into every account, means the configuration pass is the same fifty times and can be run from one checklist by someone who is not you.
- Make the custom values a data problem. If every account needs the same twenty values filled, that is a spreadsheet with twenty columns, not twenty conversations.
- Test to a script, not to taste. Fifty accounts tested “when they feel right” produces fifty different standards.
Do those four and fifty accounts is a fortnight of predictable work. Skip them and it is a quarter.
A fifty-account rollout, sequenced
This is the plan we would run, in the order we would run it. Adjust the numbers; keep the shape.
Week 0 — data. One row per account, every column filled and checked: legal name from the filing document, trading name, address, phone, email, time zone, website, and the twenty custom values the kit needs. Nothing starts until this sheet is complete, because a rollout built on half-known data produces fifty accounts each wrong in a different way.
Week 1, day 1 — creation and registration. Create all fifty from the snapshot, capture every account ID back into the sheet, provision numbers, and submit every compliance registration the same day. The registrations are now queueing in parallel with everything below.
Week 1 — domains and email. Sending subdomains published and authenticated, DNS propagating. Another wall-clock queue started early.
Week 2 — configuration. The identical pass, fifty times, from one checklist: custom values from the sheet, calendars, users, integrations, payment processors. This is the pass that must be scripted rather than improvised, and it is the one you can hand to someone else.
Week 2 — test pass. Same script every time: a form submission, a booking, a reminder, a no-show recovery, a review request, and a reply that must stop the sequence. Exit conditions are what you are really testing — see testing workflows before go-live.
Week 3 — staged go-live. Publish in tranches of ten, not all fifty at once. If something is wrong with the kit, you find it on account eleven rather than account fifty.
Two failure modes to plan around
The half-created batch. An API loop that fails at account thirty-four leaves you with thirty-three accounts and no clear record of which. Log every response, including errors, and make the log the source of truth rather than your memory of how far it got.
The registration bottleneck. If compliance approvals come back over three weeks rather than three days, your go-live date moves regardless of how good the rest of the plan was. Submit early, track per account, and never promise a client a launch date that assumes a fast approval.
What we do
Bulk sub-account provisioning exists because this is the one thing a sub-account specialist can offer that a general GoHighLevel agency cannot: the whole batch created, kit-loaded, configured from your client data, tested, and handed back with a per-account build sheet.
If you would rather run it yourself, take a kit for the vertical so the configuration pass is identical across the batch, and work from the sub-account creation order so nobody on your team invents their own.
This note is one stage ofthe complete guide to GoHighLevel sub-accounts — seven stages from a signed client to a live account.