Most people meet the GoHighLevel API the same way: something in the dashboard almost does what they need, but not quite. The workflow builder gets them ninety percent there, and then the last ten percent, the part that would actually save real time or unlock a product, needs code. That is the moment the API stops being a line item on a pricing page and becomes the difference between a setup that works and one that just looks like it does.
I run a team that builds on this API every week, wiring GoHighLevel into other systems, syncing data both directions, and writing the custom logic the native tools cannot express. So this is not a specification dump. It is the guide I wish more people had read before they called us: what the API is, how it changed in 2026, how to authenticate, where the limits are, and where the line sits between a no-code connection and a real build. If you are still getting your bearings on the platform itself, our plain explainer on what GoHighLevel is is the better first stop, then come back here.
What the GoHighLevel API actually is
Strip away the jargon and an API is just a set of doors into the software that your own code is allowed to open. The GoHighLevel API is a REST API, which means you talk to it with plain web requests: you ask a specific web address for something, you send or receive data as JSON, and you get back a status code that says whether it worked. If you have ever used any modern web service programmatically, it behaves exactly the way you would expect.
The important mental model is that almost everything you can see and click in a GoHighLevel account has a matching door in the API. A contact you can create by hand can be created by a request. A message you can send from the conversations tab can be sent by a request. An appointment, an opportunity, a form submission, a workflow enrollment: each one is a resource the API can read or change. Once that clicks, the question stops being "can the API do this" and becomes "which request does this, and how do I chain a few of them into something useful."
Here is roughly what a single call looks like in plain terms, so the shape is not a mystery.
GET https://services.leadconnectorhq.com/contacts/<contactId>
Authorization: Bearer <your-token>
Version: 2021-07-28
# The API answers with JSON: the contact's fields, tags, and more
You do not need to memorize that. The point is only that a request names the thing you want, carries a token that proves you are allowed to want it, and comes back with structured data you can act on. Everything else in this guide is variations on that one idea.
API v1 and v2, and why v1 is a dead end now
This is the single most important thing to get right in 2026, because a lot of older tutorials and even some paid courses still teach the wrong version. GoHighLevel has two generations of API, and they are not interchangeable.
| API v1 (legacy) | API v2 (current) | |
|---|---|---|
| Auth | One static API key per location | OAuth 2.0 or Private Integration Token |
| Access scope | Broad, all or nothing | Scoped to the exact data you request |
| Token safety | Key never expires until revoked | Tokens are time-limited and revocable |
| Resources | Limited | Broader, and still expanding |
| Webhooks | Minimal | First-class |
| Status | Deprecated | The one to build on |
HighLevel has deprecated v1 and is moving everyone to v2. In its own words, active v1 integrations "will continue to function for now, but they are operating without a safety net," and the company is telling people to migrate sooner rather than waiting for an outage. There is no loudly published hard shutoff date as of this writing, but "works until it suddenly does not" is not a foundation to build a business on. If you are starting anything new, target v2. If you inherited a v1 integration, put its migration on the calendar before it becomes an emergency.
Why the change at all? Security, mostly. A v1 key was one string that unlocked everything in a location and never expired, which is a liability the moment it leaks into a log file or a forwarded email. v2 replaces that with scoped tokens: an integration only gets access to the specific data it needs, tokens expire and refresh, and a leak can be revoked without breaking every other connection tied to the same account. It is more moving parts, and it is the right trade.
The two ways to authenticate
Before your code can do anything, it has to prove who it is. v2 gives you two paths, and picking the right one up front saves a lot of wasted work. The deciding question is simple: are you building something only you will use on your own accounts, or something other people will install on theirs?
Which authentication method you need
Private Integration Tokens, for your own tools
A Private Integration Token, often shortened to PIT, is the fast path. You generate it inside a sub-account's settings, choose the scopes it should have, and then send it as a bearer token on every request. It is the spiritual successor to the old v1 key, but scoped and revocable rather than all-powerful. This is what you reach for when you are automating your own agency, wiring a custom internal dashboard, or connecting GoHighLevel to a no-code tool like Make or n8n for your own use. No install flow, no consent screen, just a token you control.
OAuth 2.0, for apps other people install
The moment your integration needs to work on accounts that are not yours, a token you paste in by hand stops making sense, and you move to a full marketplace app using OAuth 2.0. You register the app on the HighLevel developer marketplace, declare the scopes it needs, and each customer installs it and grants access. In return your app receives per-location access and refresh tokens, so it can act on that customer's account until they uninstall. This is how every public GoHighLevel integration and every white-label SaaS product works under the hood.
The OAuth install flow, in five steps
The extra work of OAuth is real, but it buys you the only model that scales to a product. If you remember nothing else from this section, remember the fork: a PIT for your own accounts, a marketplace app for everyone else's. Building the wrong one means rebuilding it later.
What you can actually build with it
Specs are abstract, so here is the concrete version: the resources the v2 API exposes, and a real thing each one is good for. This is not the full list, and HighLevel keeps adding to it, but it covers the work that comes up again and again.
| Resource | What it lets you do | A real reason to use it |
|---|---|---|
| Contacts | Create, read, update, search, tag | Push leads in from a source GoHighLevel does not natively connect to |
| Conversations and messaging | Send and read SMS, email, and channel messages | Drive outbound messaging from your own app, logged inside GoHighLevel |
| Calendars and appointments | Read availability, book, reschedule, cancel | Sync bookings with an external scheduling or field-service system |
| Opportunities and pipelines | Create and move deals, update value and stage | Keep the sales pipeline honest from another system of record |
| Forms and submissions | Read submitted data | Route a form answer into custom logic the native builder cannot run |
| Payments and orders | Read orders, transactions, subscriptions | Reconcile billing or trigger fulfilment when money moves |
| Users, locations, companies | Provision and manage accounts and users | Spin up new client sub-accounts programmatically at the agency level |
| Workflows | Enroll contacts, trigger via inbound webhook | Let an outside event kick off a GoHighLevel automation instantly |
One honest note on scope. Most of the API lives at the location, or sub-account, level, which is where day-to-day work happens. Company or agency-level actions exist too, provisioning new sub-accounts is the common one, but they are more limited and gated more tightly than location-level calls. If your plan depends on doing something sweeping across every account at once, confirm the exact capability in the docs before you promise it to anyone.
The magic is rarely one endpoint. It is chaining a few together into a flow the dashboard cannot do on its own. A lead lands in your own software, you create the contact, tag it, drop it into a workflow, and book the appointment, all in one automated pass. That kind of glue is exactly what we cover from the no-code side in our guide to integrating GoHighLevel with Zapier and Make, and the API is the version of the same idea with no ceiling.
Webhooks: the half most people forget
There are two ways to move data between systems, and beginners almost always pick the worse one first. You can pull, meaning your code asks the API over and over whether anything has changed, or you can be pushed to, meaning GoHighLevel tells your endpoint the instant something happens. Pulling is simple to picture and terrible at scale: it wastes requests, adds delay, and marches you straight toward the rate limits. Webhooks are the push model, and for anything that needs to feel instant, they are the right tool.
In practice a webhook is a web address you own that GoHighLevel calls with a small packet of JSON when an event fires: a new contact, an inbound message, a completed appointment. GoHighLevel can send these from inside a workflow, which is the easiest on-ramp, and a marketplace app can subscribe to events at the app level. The payoff is real. A webhook-driven integration reacts in real time and barely touches your request budget, where the same job built on polling is slower and noisier and far more likely to hit a limit on a busy day.
The rule of thumb we build by: use webhooks to know that something happened, and use the API to do something about it. Combine the two and you get integrations that feel immediate without hammering anything.
Rate limits, and how not to hit them
Every serious API caps how fast you can call it, and GoHighLevel is no exception. For a marketplace app, HighLevel documents these limits, counted per app per resource, where a resource is a single Location or Company:
- Burst limit: 100 requests per 10 seconds.
- Daily limit: 200,000 requests per day.
For most builds those numbers are generous, and you will never come close. You hit them by doing something naive: looping through ten thousand contacts one request at a time, or polling for changes every few seconds across a lot of accounts. The good news is that the API tells you exactly where you stand. Every response carries rate-limit headers reporting your remaining daily budget and your remaining budget in the current burst window, so well-behaved code can watch those numbers and slow itself down before it ever gets blocked.
Three habits keep you comfortably clear of the ceiling. Prefer webhooks over polling so you are not asking for changes that have not happened. Batch and paginate deliberately instead of firing one request per row. And build in automatic backoff, so when you do approach a limit your code queues and retries calmly rather than slamming into a wall. None of this is exotic. It is the difference between an integration that survives a busy Monday and one that quietly falls over when it matters most.
Not sure whether your idea needs the API at all?
Sometimes a workflow or a no-code connection does the job, and sometimes it genuinely needs custom code. Tell us what you are trying to build, and we will tell you the shortest honest path to it, even when that path skips us entirely.
Book a callThe API versus Zapier and Make
This is the question we get more than any other, and the answer is not "always code." No-code tools like Zapier and Make talk to GoHighLevel perfectly well, and for a huge share of everyday automation they are the right call: faster to stand up, easier for a non-developer to maintain, and cheaper for low volume. If your need is "when a form is submitted, add a row to a sheet and send a Slack message," do not write software for that.
You cross into API territory when one of a few things is true. You need custom logic the no-code tool cannot express, like a pricing calculation or a conditional the visual builder cannot model. You need genuine two-way sync, where both systems update each other and stay consistent. You are moving high volume, where per-task no-code pricing gets expensive and a direct integration is cheaper and faster. Or you are building a product other people will install, which needs the OAuth model no-code cannot provide. When you see two or three of those at once, a real build stops being over-engineering and starts being the responsible choice.
We wrote the full no-code decision path, including where Zapier and Make each fit, in our GoHighLevel integration guide. Read that first if you are not sure your case has outgrown no-code yet. Most have not, and that is fine.
What the API cannot do, honestly
A guide that only sells the upside is not much use, so here are the walls you will actually meet.
- It is not a magic wand for missing features. If a capability does not exist in GoHighLevel, the API cannot invent it. It exposes what the platform already does, faster and programmatically, and no more.
- Coverage is not total. The v2 surface is broad and growing, but not every corner of the dashboard has an endpoint yet. Occasionally the thing you want is not exposed, and you have to design around it or wait for HighLevel to add it.
- Company-level power is limited. As covered above, sweeping agency-wide actions are more constrained than per-location ones. Plan for that rather than discovering it late.
- It changes underneath you. A live API evolves. Endpoints get added, behavior gets refined, and an integration that is never maintained will eventually drift. Budget for upkeep, not just the initial build.
- It does not remove the need to know the platform. The hardest part of most integrations is not the HTTP. It is understanding how GoHighLevel models contacts, workflows, and accounts well enough to not corrupt data. That knowledge is the real prerequisite.
What we build on it
The abstract case for the API only lands when you see what it turns into, so here is real work from our own case studies rather than a hypothetical.
A field service business was drowning in double data entry between GoHighLevel and Housecall Pro, the classic two-tools-that-do-not-talk problem. There is no native connector for that pair, so we built one on the API: a bi-directional integration that reached 100 percent automated contact sync between the two systems, ending manual entry entirely and giving the field and office teams the same real-time view. That is the API doing exactly what it is for: making two systems behave like one.
An events business needed pricing logic and installment billing that GoHighLevel's native forms could not express on their own. Rather than tell them it was impossible, we wrote dynamic pricing and tamper-proof, backend-calculated installment billing straight into their GoHighLevel forms with custom scripting, so the numbers could not be manipulated in the browser and cash flow became predictable. And for a multi-practice healthcare group, we embedded a custom analytics app right inside their GoHighLevel account, with AI reading live data to surface growth recommendations. None of those ship in the box. All of them are the platform plus the API plus a team that knows how to join them.
That last ingredient is the quiet one. The code is rarely the hard part. Knowing GoHighLevel's data model well enough to build on it without breaking anything is, which is most of what our HighLevel Certified team actually sells, and it is the same expertise behind the white-label work we do for agencies through our GoHighLevel white-label fulfillment service.
A sane first build, in order
If you are going to try this yourself, do it in the order that fails cheaply. The mistake we see most is someone writing the whole integration before they have made a single call work, then spending a weekend untangling which of ten new things is broken. Prove each layer before you add the next.
The order that saves you a weekend of debugging
Create a Private Integration Token, then read a single contact by id. Nothing else until that returns clean.
Update a field or add a tag on that contact. Now you have proven read and write, the two halves of everything.
Fire a workflow webhook at a test endpoint and confirm you receive the payload. This is your real-time trigger.
On that webhook, run your logic and call the API back, create, tag, book, message. This is your actual integration.
Add error handling, respect the rate-limit headers, log failures, and only then point it at live data.
Do it in that sequence and every problem stays small, because you only ever added one new thing since the last time it worked. Skip the sequence and you are debugging a black box. This is the same build discipline we use on client work, just scaled down to a first project.
Where to go from here
The GoHighLevel API in 2026 is a capable, modern REST API on OAuth 2.0, and it is the thing that turns the platform from a very good all-in-one tool into a foundation you can build a genuinely custom operation, or a whole product, on top of. Start with the two authentication paths, lean on webhooks so you stay fast and under the limits, and respect what the API cannot do so you design around the walls instead of into them.
The official v2 documentation on the HighLevel marketplace developer portal is the source of truth for exact endpoints and scopes, and you should treat any third-party guide, this one included, as the map rather than the territory, because the API keeps moving. If your idea has clearly outgrown no-code, or you want a second opinion on whether it has, that is the work we do all day. When you are ready to build, or just to find out whether you should, our team is a short call away.
Frequently asked questions
Is the GoHighLevel API free to use?
Creating a developer account on the HighLevel marketplace and building against the API does not cost extra on top of a paid plan. What you pay for is the underlying usage: SMS, email, and AI actions your integration triggers are billed the same way they are inside the dashboard. Some higher-tier capabilities and white-label features tie to the $297 and $497 plans, so check your plan, and our GoHighLevel pricing guide, before you scope a build.
What is the difference between GoHighLevel API v1 and v2?
v1 used a single static API key per location with broad access. v2 is a modern REST API built on OAuth 2.0 with scoped, time-limited tokens, more resources, and webhooks. HighLevel has deprecated v1 and is steering everyone to v2. Existing v1 integrations still run for now, but they run without a safety net, so any new build should target v2.
How do I authenticate with the GoHighLevel API?
Two ways. For an internal tool that only touches your own accounts, a Private Integration Token is the fast path: generate it in the sub-account settings and send it as a bearer token. For an app that other accounts install, you register a marketplace app and use the OAuth 2.0 authorization code flow to get scoped access and refresh tokens per location.
What are the GoHighLevel API rate limits?
For a marketplace app, HighLevel documents a burst limit of 100 requests per 10 seconds and a daily limit of 200,000 requests, counted per app per resource (Location or Company). Every response carries rate-limit headers so you can see your remaining budget and back off before you hit the wall.
Can the GoHighLevel API send SMS and emails?
Yes. The conversations and messaging endpoints let you send and read SMS, email, and other channel messages, and read full conversation threads. This is one of the most common reasons teams reach for the API: driving outbound messaging from their own system while keeping every message logged inside GoHighLevel.
Do I need a developer to use the GoHighLevel API?
For a simple connection, no. Tools like Zapier and Make talk to GoHighLevel without code and cover most everyday automations. You need a developer once you want custom logic, two-way sync, high volume, or anything the no-code path cannot express. That is the line where a real build starts paying for itself, and it is where our team spends most of its time.
Is there a GoHighLevel webhook I can use instead of polling?
Yes, and you usually should. Webhooks push an event to your endpoint the moment something happens, so you react in real time instead of asking the API over and over whether anything changed. GoHighLevel can fire webhooks from workflows and from app-level subscriptions, which keeps your integration fast and keeps you well under the rate limits.
Where is the official GoHighLevel API documentation?
The current v2 developer documentation lives on the HighLevel marketplace developer portal at marketplace.gohighlevel.com/docs, alongside the app creation flow, OAuth setup, webhook guides, and the rate-limit reference. Treat it as the source of truth, because endpoints and scopes change and any third-party guide, including this one, can fall out of date.