Every GoHighLevel limit we could verify at the source

Limits are the figures that decide whether a build works at scale, and they are the ones hardest to find a straight answer on. Most of what circulates is someone’s recollection of a limit from a previous platform version.

Every number below was read off HighLevel’s own documentation on 16 September 2026, and every row links to the page we read it on. Where the documentation does not state something, it is listed at the bottom as not stated rather than filled in from a reasonable guess.

API rate limits

From HighLevel’s rate limits documentation, read 16 September 2026.

Limit	Published value
Burst	100 API requests per 10 seconds
Daily	200,000 API requests per day

Both apply to the API v2 endpoints.

The scope is the part that catches people out

The limits are counted per Marketplace app, per resource, where a resource is a single Location (a sub-account) or a Company (the agency).

That scoping is more generous than it first reads. Because the quota attaches to the app and the resource together, installing across more sub-accounts does not divide one allowance between them. Each install carries its own budget. An agency with forty sub-accounts is not sharing 200,000 calls a day across forty clients.

The inverse is the trap. A single integration that hammers one busy sub-account is competing only with itself, and no amount of spare capacity on the other thirty-nine helps it.

The headers are the only honest way to know where you are

Every API response carries your current position against both limits. The published header names are:

Header	What it reports
X-RateLimit-Max	The ceiling for the burst interval
X-RateLimit-Remaining	Calls left in the current interval
X-RateLimit-Interval-Milliseconds	The length of that interval
X-RateLimit-Limit-Daily	The daily ceiling
X-RateLimit-Daily-Remaining	Calls left today

If you are building anything that runs unattended, read these rather than counting your own calls. A retry loop that does not look at X-RateLimit-Daily-Remaining will burn a day’s quota rediscovering that it has run out.

LC Email daily sending limits, shared domain

A separate system with separate numbers. From HighLevel’s LC Email sub-account ramp-up documentation, read 16 September 2026.

Stage	Daily limit
1 (starting)	1,000
2	2,500
3	5,000
4	6,500
5	8,000
6	10,000
7	14,000
8	15,000
9 (maximum)	25,000

Brand-new sub-accounts open at Stage 1 with a “Warming up” status, and the stage rolls forward automatically as sending performance stays healthy.

Stages move down as well as up. The documentation names bounce spikes, a delivery rate falling below 95%, and spam complaints above threshold as causes of a downgrade. So the limit that applies to a sub-account is a function of how it has been sending, not a fixed property of the plan.

A dedicated domain goes considerably further

From HighLevel’s domain warmup documentation, read the same day. A dedicated domain runs a fifteen-stage model rather than nine.

Stage	Daily limit	Stage	Daily limit
1	1,000	9	25,000
2	2,500	10	35,000
3	5,000	11	50,000
4	6,500	12	80,000
5	8,000	13	125,000
6	10,000	14	175,000
7	14,000	15	250,000
8	20,000

Warmup completes at Stage 15, at 250,000 emails a day.

The two tables diverge at stage 8, and nowhere else

Worth noticing if you are planning a migration. Stages 1 through 7 are identical on both models. At stage 8 the shared-domain table reads 15,000 and the dedicated-domain table reads 20,000, and from stage 9 the shared model stops at its maximum of 25,000 while the dedicated model continues to ten times that.

The practical reading: a shared domain is not a slower path to the same ceiling. It is a different ceiling. Anyone planning to send above 25,000 a day needs the dedicated domain in the plan from the start, because the stages have to be climbed either way.

Progression on the dedicated model has a condition attached that the shared model does not state. The documentation is explicit: progression occurs only when the full daily limit for the current stage is reached, and if the daily limit is not met the domain stays where it is. Sending 5,000 a day against a 6,500 stage does not eventually promote you. It holds you there.

What we could not verify, and did not quote

Three things are absent above because the documentation does not state them, and a reference page that fills its own gaps is worse than one with holes in it.

• The HTTP status code returned when a rate limit is exceeded. The rate limits page describes both limits and the headers but does not name the response code. 429 is the conventional answer and it is not what the page says, so it is not quoted here.
• How long warmup takes in days. The fixed-stage model page gives the stages and the condition for advancing, but no total duration. Since advancement depends on actually hitting each daily limit, the honest answer is that it depends on volume rather than elapsed time.
• The numeric thresholds for a shared-domain stage upgrade. Downgrade causes are named, including the 95% delivery rate. The upgrade criteria are described only as sending performance staying healthy.

Using these figures

Check the date at the top. These were read on 16 September 2026 and vendors change them without announcement, so treat this page as a dated reading rather than a standing fact, and follow the links before you rely on a number in a build.

For plan pricing, A2P 10DLC throughput and the Gmail bulk sender thresholds, the companion reference is GoHighLevel cost and compliance figures, which is sourced the same way.