GoHighLevel API: Auth, Versions, Rate Limits and Coverage (2026)

Short answer: yes. GoHighLevel ships a documented, versioned, public REST API with OAuth support, published rate limits, webhooks and a developer marketplace. If you were expecting a thin, half-documented endpoint list, that is not what is there. Everything below is taken from HighLevel’s own developer portal, checked on 2 September 2026, with the source page named for each claim so you can verify it yourself rather than take our word for it.

The interesting part is not the yes. It is the shape of the surface: which versions are live, what the two token models can and cannot do, where the ceiling sits, and what the documentation does not tell you. Those are the details that decide whether an integration you build this quarter is still standing next year.

Does GoHighLevel have an API?

GoHighLevel, which brands the platform as HighLevel in its developer material, publishes a REST API documented at marketplace.gohighlevel.com/docs. The portal describes itself as “Complete REST API documentation for the HighLevel CRM platform” and groups coverage under CRM and Contacts, Conversations, Calendar and Events, Opportunities, Payments and Webhooks.

The base URL is https://services.leadconnectorhq.com. The portal’s own quick-start example is a plain bearer-token GET:

curl -X GET \
  https://services.leadconnectorhq.com/contacts/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json"

That leadconnectorhq.com hostname trips people up on first contact. LeadConnector is the white-label brand HighLevel uses across several of its own surfaces, and the API lives there rather than on gohighlevel.com. If you are searching your firewall or proxy logs for API traffic, that is the domain to look for.

Two integration paths exist, and the documentation is explicit that you should choose deliberately between them: a Marketplace app, or a private integration. The choice drives which authorization method you use, which in turn drives what your integration can reach. That is covered below.

API versions and the Version header

HighLevel’s API Versioning page states that the version is specified per request using the Version request header, and that two versioning schemes have been used over time:

• Date-based versions. Earlier versions used a date string as the identifier, for example 2021-07-28, passed verbatim in the Version header.
• Named versions. Starting with v3, versions use a named identifier such as v3 or v4, passed in the same header.

The documentation portal’s version selector currently offers four choices: v3, 2023-02-21, 2021-07-28 and 2021-04-15. Note that the selector lists versions of the documentation. HighLevel’s versioning page has a “Supported Versions” table for the authoritative list, so treat the selector as a strong indicator rather than a support commitment.

The deprecation policy is stated plainly, and it is worth reading before you pin a version and forget about it. When a new version ships, the previous one enters a maintenance window where it receives critical bug fixes and security patches but no new features. Once a version is retired, requests carrying that version header are no longer accepted. HighLevel recommends migrating to the latest supported version before the retirement date.

The practical consequence: a per-request version header is a good design, because it lets you migrate endpoint by endpoint instead of flipping the whole integration at once. But it also means the version string is scattered across every call site in your codebase. Put it in one constant on day one. Teams that hard-code 2021-07-28 in forty places tend to discover this the week a retirement notice lands.

Authentication: OAuth, Private Integration Tokens, and the legacy API key

HighLevel’s Authorization page states that the platform “currently supports two types of authorization”: a Private Integration Token and an OAuth 2.0 flow. The documentation gives explicit guidance on which to pick.

When HighLevel says to use a Private Integration Token

Per the Authorization page, a Private Integration Token fits when your use case involves accessing the API endpoints for internal purposes, when you do not need webhooks or custom design or pages, and when you need to access only one sub-account at a time. The example use cases it names are internal data synchronization, custom reporting dashboards, and automated tasks inside your own system.

When HighLevel says to use OAuth 2.0

OAuth is the documented path when you are developing a full-scale integration intended for public use, when your integration requires features such as webhooks and custom modules, and when you need advanced security features and standardized authorization management. Named use cases: third-party applications, custom conversation providers and custom workflow actions or triggers, and services requiring secure user authorization.

Read that list carefully, because there is a real constraint hiding in it. If you need webhooks, the documentation points you at OAuth, not at a Private Integration Token. A lot of internal integrations start as a PIT-based script, then grow a requirement for real-time events, and at that point the auth model has to change rather than extend.

The legacy API key path is end-of-life

HighLevel’s Private Integrations page carries a blunt comparison table against the older API-key approach. In HighLevel’s own words, API keys give a developer “unrestricted access to all your account data,” they work on API v1.0 which “has reached end-of-life and is no longer maintained,” and v1.0 has “limited APIs” relative to v2.0. Private Integrations, by contrast, let you restrict the scopes a developer can reach.

If you inherited a GoHighLevel integration built before Private Integrations existed, that paragraph is your migration brief. An unscoped key on an unmaintained API version is the kind of thing that is fine right up until it is not.

Token handling details worth knowing

Several operational facts come straight from the same page. Private Integration Tokens are static and do not auto-refresh, whereas OAuth access tokens expire daily and need refreshing. HighLevel recommends rotating Private Integration tokens every 90 days, and rotation gives you a seven-day window where the old and new tokens both work before the old one expires, with options to cancel the rotation or expire the old token immediately. You can edit a Private Integration’s name, description and scopes at any time without generating a new token. The token is shown once, so if you do not copy it at creation you will be rotating rather than retrieving.

By default all agency admins can create and manage Private Integrations, and that permission can be restricted per user under Settings, then Team, then Roles and Permissions, at two levels: the agency’s own private integrations, and the sub-accounts’ private integrations. Private Integrations are available for both agencies and sub-accounts.

The industry guides show how Conduyt is set up for agencies, contractors, mortgage teams and more.

What the API actually covers

The v3 reference navigation on the developer portal lists more than 40 distinct resource groups. Counted from the sidebar on 2 September 2026, they are: OAuth 2.0, Ad Manager, Affiliate Manager, AI Agent Studio, Associations, Blogs, Brand Boards, Business, Calendars, Campaigns, Chat Widget, Companies, Contacts, Conversation AI, Conversations, Courses, Custom Fields V2, Custom Menus, Email ISV, Email, Files, Forms, Funnels, Invoice, Knowledge Base, Trigger Links, Sub-Account (formerly Location), Developer Marketplace, Media Storage, Objects, Opportunities, Payments, LC Phone, Products, Proposals, SaaS, Snapshots, Social Planner, Store, Surveys, Users, Voice AI and Workflows.

That is a wide surface, and the shape of it tells you what the platform is for. Funnels, Snapshots, SaaS, Affiliate Manager and Social Planner are agency-resale primitives. You do not find them on a general-purpose sales CRM’s API, and if your business is reselling marketing operations, their presence is a genuine reason to build here.

A caution on counting. Resource groups are not endpoints, and neither is an operation. A vendor can list 40 groups covering 100 operations or 1,000, and the sidebar looks identical either way. We are quoting the group count because it is what the documentation actually publishes. We could not find a public, unauthenticated, machine-readable catalog of GoHighLevel’s total endpoint or operation count, so we are not publishing one. If you need that number, count it yourself against the version you intend to use.

Rate limits, and how to read them correctly

HighLevel’s Rate Limits page states that limits apply to the public API 2.0 endpoints authenticated with OAuth, and publishes them directly:

The scoping rule is the part that changes your architecture. Limits are counted per Marketplace app (client) per resource, where a resource is a single Location, meaning sub-account, or a single Company, meaning agency. HighLevel’s own worked example: an app installed on sub-accounts A and B may make 200,000 requests per day and 100 per 10 seconds against A, and the same again independently against B. Installing on more sub-accounts does not divide your allowance.

For an agency running an integration across many client accounts, that is a materially better model than a single pooled quota, because one noisy sub-account cannot starve the others. It also means your backoff logic has to be keyed per sub-account, not global, or you will throttle accounts that had budget to spare.

The documentation also tells you to read the response headers rather than counting requests yourself, and calls them authoritative: X-RateLimit-Limit-Daily, X-RateLimit-Daily-Remaining, X-RateLimit-Interval-Milliseconds, X-RateLimit-Max and X-RateLimit-Remaining. That is good advice for any API. Client-side counters drift the moment a retry, a parallel worker or a second deploy enters the picture.

One boundary worth flagging: the page scopes these limits to endpoints authenticated with OAuth. It does not publish a separate figure for Private Integration Token traffic. We are not going to guess at one.

Webhooks and the Marketplace app path

The developer portal’s landing page describes webhooks as “Real-time notifications for 50+ events” and links a dedicated webhook category, a Webhook Integration Guide and a Webhook Logs Dashboard. As noted above, the Authorization page routes webhook-dependent integrations to OAuth rather than to a Private Integration Token.

The Marketplace path adds its own steps beyond writing code. HighLevel’s Getting Started section for the Developer Marketplace covers app creation, an app testing guide, app review guidelines, an update process, external billing, external authentication and marketplace policies including private app install limits. If you are shipping something other people install, budget for review, not just for build.

For context on scale, the same Getting Started page states that HighLevel has “over 70000+ agencies 600,000+ businesses actively using our product.” That is the vendor’s own marketing figure on its own developer page, quoted as such and not independently verified here.

Where the MCP server fits

The API is not the only way an AI agent reaches a GoHighLevel account. HighLevel also documents a LeadConnector MCP server, and the developer-portal version of that page describes a per-client endpoint pattern at https://services.leadconnectorhq.com/mcp/{client}/v2, live for Claude at /mcp/anthropic/v2, alongside the original https://services.leadconnectorhq.com/mcp/ endpoint. It states that both endpoints support OAuth and Private Integration Token auth, and that the per-client endpoint exposes a compact unified toolset backed by “hundreds of operations across 40 domains,” while the original endpoint exposes a narrower, focused core toolset.

If your team works in Claude, the Claude Desktop CRM connection lets the assistant read and update records through MCP.

Two things follow. First, MCP here is a layer over the same REST surface and the same scope model, so everything above about tokens and scopes still governs what an agent can do. Second, HighLevel’s MCP documentation has moved quickly, and material published even a couple of months ago may describe a different auth story than the current developer portal does. Check the live page before you quote a version of it. Our longer breakdown is at GoHighLevel MCP server: setup, tools and limits.

How to evaluate a CRM API before you build on it

Whichever platform you land on, these are the questions that separate an API you can plan around from one you will keep rediscovering. None of them is about endpoint count.

1. Is there a machine-readable catalog you can fetch without logging in? A human-readable docs site tells you what exists today. A fetchable schema tells you what changed since last month, which is the thing that actually breaks integrations.
2. How is the version selected, and what is the retirement policy? A per-request header with a stated maintenance window, which is what GoHighLevel publishes, is a good answer. Silence is not.
3. Does the auth model you need today support the features you will need in six months? The webhook constraint on Private Integration Tokens is a clean example of a decision that is cheap now and expensive later.
4. Are rate limits published, and how are they scoped? Per-tenant scoping and authoritative response headers, both of which GoHighLevel publishes, are the two details that make backoff logic writable.
5. Does API access depend on your plan tier or your seat count? This is where per-seat pricing quietly becomes an API problem. If adding an integration user costs a seat, your automation budget is a headcount line.
6. What is the blast radius of a leaked credential? Scoped tokens with a documented rotation window beat an unscoped key on an unmaintained API version, every time.

How Conduyt approaches the same problem

Conduyt is a flat-rate, AI-native CRM, and its answer to question one above is to publish the catalog itself. The public schema endpoint at conduyt.app/api/v1/schema/public returns the live counts without an account, which is also how the figures we publish stay honest: 610+ API endpoints, 880+ API operations and 100+ API domains, alongside 170+ MCP tools for agent access. If those numbers move, the endpoint moves with them, and you can diff it on a schedule.

On question five, the pricing model is the point. Conduyt is 299/mo flat, with unlimited users and no per-seat fees, so an integration user, a service account or a fifth teammate does not change the bill. There is a 20-day trial with no card required if you want to point a client at it before committing. For the wider comparison, see our best GoHighLevel alternatives for 2026 and our guide to auditing an API-first CRM before you buy.

To be clear about the trade: GoHighLevel’s API covers agency-resale surfaces, Snapshots, SaaS mode, Affiliate Manager, Funnels, that Conduyt does not attempt. If your business is reselling marketing operations under your own brand, that coverage is a real reason to stay. If what you need is a deep, diffable, predictably priced CRM surface for agents and internal systems, that is the case we would make for switching. Neither of those is a promise about your results.

Frequently asked questions

Does GoHighLevel have an API?

Yes. GoHighLevel, branded HighLevel in its developer material, publishes a versioned public REST API with a base URL of https://services.leadconnectorhq.com and documentation at marketplace.gohighlevel.com/docs, covering contacts, conversations, calendars, opportunities, payments, webhooks and more than 40 resource groups in total.

What are the GoHighLevel API rate limits?

The HighLevel rate limits page publishes a burst limit of 100 API requests per 10 seconds and a daily limit of 200,000 API requests, applied to public API 2.0 endpoints authenticated with OAuth. Limits are counted per Marketplace app per resource, where a resource is one sub-account or one agency, so installing on more sub-accounts does not divide the allowance.

Should I use OAuth or a Private Integration Token with the GoHighLevel API?

The HighLevel authorization documentation points to a Private Integration Token for internal use against a single sub-account when you do not need webhooks or custom pages, and to OAuth 2.0 for public integrations, or any integration that needs webhooks or custom modules. If webhooks are on your roadmap, starting on OAuth avoids a later migration.

Is the GoHighLevel API key still supported?

The HighLevel Private Integrations documentation states that API keys work on API v1.0, which has reached end-of-life and is no longer maintained, and that keys give unrestricted access to all account data. Private Integrations with scoped permissions on API v2.0 are the documented replacement.

What GoHighLevel API versions are available?

The developer portal version selector offers v3, 2023-02-21, 2021-07-28 and 2021-04-15. The version is chosen per request through a Version request header. Older versions enter a maintenance window with critical fixes only, and retired versions stop being accepted.

How does the Conduyt API compare with the GoHighLevel API?

Conduyt publishes a machine-readable public schema at conduyt.app/api/v1/schema/public reporting 610+ API endpoints, 880+ API operations and 100+ API domains, plus 170+ MCP tools, on flat-rate pricing of 299/mo with unlimited users and no per-seat fees. GoHighLevel publishes documentation for more than 40 resource groups, including agency-resale surfaces such as Snapshots, SaaS and Funnels that Conduyt does not offer.