GoHighLevel custom development means building software on top of the HighLevel platform: marketplace apps other agencies install, private integrations that automate your own sub-accounts, and custom UI that lives right inside the CRM. If you can call a REST API and handle an OAuth redirect, you can build it. This guide is the map. It covers the three ways to build, the API v2 essentials you'll touch on day one, and how to pick the right approach so you don't rebuild everything six months from now.
Here's the short version. If you're automating your own account, use a Private Integration Token. If you're building something other agencies will install, build a Marketplace app with OAuth. Everything else is detail, and the detail is what this guide walks through.
What GoHighLevel custom development actually is
HighLevel ships with workflows, funnels, a calendar, a pipeline, and a hundred other features. Custom development starts where those stop. Maybe you need to sync contacts to an external system the moment a deal moves stage. Maybe you want a branded onboarding screen inside the sub-account. Maybe you're building a SaaS product and GoHighLevel is the CRM layer underneath it. All of that runs through the same public API and app platform.
There are three building blocks, and most real projects use more than one:
- Private Integrations: a single token that authorizes calls against your own agency or sub-account. No install flow, no OAuth. Best for internal automations and client work you run yourself.
- Marketplace apps: distributable apps that any HighLevel account can install. These use OAuth 2.0, so each install grants your app scoped access to that account. This is how you reach thousands of agencies.
- Custom Pages and custom UI: in-app experiences (onboarding, settings, dashboards) that render inside HighLevel for accounts that installed your app.
We go deep on the token-versus-app decision in Private Integration Tokens vs Marketplace Apps, because getting it wrong is the single most common early mistake.
The API v2 essentials
Everything modern runs on API v2. The old v1 keys still work in places, but new features and webhooks land on v2, so start there. Three things are true of almost every v2 request.
The base URL is https://services.leadconnectorhq.com. Contacts live at /contacts/, opportunities at /opportunities/, and so on. The marketplace docs at marketplace.gohighlevel.com/docs are the source of truth for the exact paths, and you should treat them as such because endpoints do change.
Every v2 request needs a Version header. It looks like Version: 2021-07-28. The one request that doesn't need it is the token exchange. Miss the header and you'll get an error that doesn't obviously say "you forgot the version," so set it once in your HTTP client and forget it.
Auth is a bearer token, whether that token came from a Private Integration or from the OAuth flow. A typical call looks like this:
const res = await fetch('https://services.leadconnectorhq.com/contacts/', {
method: 'GET',
headers: {
Authorization: `Bearer ${accessToken}`,
Version: '2021-07-28',
Accept: 'application/json',
},
});
That's the shape of the whole API. Once you have a valid token and the version header, the rest is reading the docs for the resource you care about.
Authentication: two doors into the same house
Private Integration Tokens are the easy door. You open the sub-account or agency settings, create a Private Integration, pick the scopes it needs, and copy the token. HighLevel shows it once, so store it in a secret manager immediately. From then on it's just a bearer token. There's no refresh, no expiry to babysit, and the recommendation is to rotate it every 90 days.
OAuth 2.0 is the door for distributed apps. Your app sends the agency to a HighLevel authorization screen, they pick which location to grant, and HighLevel redirects back with a code you exchange for tokens. Access tokens last about 24 hours and refresh tokens rotate on every use. The full flow, with working code, is in How to Build a GoHighLevel Marketplace App with OAuth 2.0.
Rate limits you'll actually hit
HighLevel enforces two limits per app per resource (a resource is a location or company). The burst limit is 100 requests every 10 seconds. The daily limit is 200,000 requests per day. Those are generous for most apps and painful for bulk jobs if you're careless.
The fix is to read the response headers instead of guessing. Every response tells you where you stand:
// After any v2 request
const remaining = res.headers.get('X-RateLimit-Remaining'); // this burst window
const dailyLeft = res.headers.get('X-RateLimit-Daily-Remaining'); // today
if (Number(remaining) < 5) {
await new Promise((r) => setTimeout(r, 1200)); // let the 10s window roll over
}
For anything that loops over thousands of contacts, add a small concurrency cap and back off when X-RateLimit-Remaining gets low. That one habit prevents almost every "my sync randomly fails" support ticket.
Webhooks: build reactive, not polling
Polling the API on a timer wastes your rate limit and lags reality. Webhooks flip it around. You subscribe to events (a contact created, an opportunity stage changed, a payment failed), HighLevel posts to your endpoint, and you react. For a Marketplace app you also get workflow triggers your users can drop into their automations, which is often the real reason people install an app in the first place.
The rule with webhooks is to verify and respond fast. Acknowledge the delivery with a 200 quickly, then do the slow work in a background job. If your handler is slow or flaky, you'll get retries and duplicate processing, so make your handler idempotent from the start.
Custom UI inside HighLevel
Custom Pages let a Marketplace app render its own screens inside the HighLevel interface: an onboarding flow, a settings panel, a reporting dashboard, whatever your app needs. To the user it feels native. To you it's your own web app loaded in context with the account it's serving. This is what turns a background integration into a product people can see and click.
Why 2026 is a good time to ship
HighLevel isn't charging commission on developer revenue until the end of 2026. If you've been sitting on an app idea, that window matters: you keep everything you earn from installs during it. Pair that with the new AI-agents-in-workflows feature, which can call external tools through MCP, and there's a genuinely fresh category of apps to build that didn't exist a year ago.
A sensible build order
Start small and local. Create a Private Integration Token, make a few real API calls against your own sub-account, and get comfortable with the version header and rate limits. Once that clicks, decide whether your idea is internal (stay with tokens) or distributable (move to OAuth and the marketplace). Only then wire up webhooks and custom pages. Building in that order means every step works before you add the next one.
From here, pick your path. If you're distributing, read the OAuth marketplace app guide next. If you're still deciding, the tokens versus apps comparison will save you a rebuild.
Frequently asked questions
Do I need to know a specific language to build on GoHighLevel?
No. The API is plain REST over HTTPS, so any language that can make HTTP calls works. Node.js and PHP are the most common in the community, mostly because of the hosting options, not because HighLevel requires them.
Is API v1 dead?
Not dead, but don't start there. v1 API keys still function for some older endpoints, but new capabilities and webhooks are v2 only. Build on v2 and you won't have to migrate later.
How much does it cost to publish a Marketplace app?
You need a developer account on the marketplace, and apps go through a review before listing. HighLevel isn't taking commission on developer revenue until the end of 2026, which is the main reason people are shipping now.
Can I use the API without building a full app?
Yes. That's exactly what Private Integration Tokens are for. Create a token in your account settings, and you can automate that account without any OAuth or marketplace review.




