On this page
Key facts at a glance
| Question | Answer |
|---|---|
| What is the job? | Build what HighLevel menus cannot: OAuth, webhooks, Marketplace apps, Voice AI into the CRM. |
| Admin or developer? | A Certified Admin configures the product. A developer builds beside it when two systems must write the same record. |
| Does every problem need a developer? | No. If the whole fix lives in the dashboard, stay in the dashboard. |
| Which API? | Current work is HighLevel API v3: scoped OAuth, tokens, webhooks and Marketplace apps. |
| Who keeps the account? | You do. The sub-account and the data stay in your name throughout. |
What does a GoHighLevel developer actually do?
A GoHighLevel developer builds the work the native menus cannot do: scoped OAuth, webhooks, Marketplace apps, and Voice AI that writes into the same contact as the rest of the CRM.
The dashboard is powerful. Pipelines, workflows, calendars, snapshots and funnels cover most of what an agency needs day to day. You call a developer when two systems must write the same contact, when a new sub-account has to be stood up from an API rather than a checklist, or when a voice agent has to book into HighLevel without a human copying the notes.
In practice that means scoped OAuth, webhooks that still fire after a token refresh, custom Marketplace apps, and MCP tools so an agent can search and act instead of guessing. That is the work behind HighLevel MCP servers and API integrations, and behind custom Marketplace app development.
Current work is HighLevel API v3: OAuth, scoped tokens, webhooks and Marketplace apps. That is the surface in the Marketplace API documentation and the LeadConnector MCP docs. The developer community is the door into those docs. If it cannot be done in the dashboard, it is developer work.
What is the difference between a Certified Admin and a developer?
A Certified Admin configures what HighLevel already does in the dashboard; a developer builds what the product cannot do alone, using API v3, OAuth, webhooks and systems that sit beside HighLevel.
The industry uses these titles loosely. The useful split is where the work lives, not what is printed on a proposal.
| Role | Where they work | Hire them when |
|---|---|---|
| Certified Admin | Inside HighLevel: pipelines, workflows, snapshots, calendars, funnels. | The fix lives entirely in the dashboard. |
| Developer | OAuth, webhooks, Marketplace apps, servers beside HighLevel, Voice AI that books into the CRM. | Two systems write the same record, or the native builders have run out. |
| Verified Developer Partner | HighLevel's own listing for people who ship Marketplace apps, not a self-awarded badge. | You need the platform layer, not another snapshot. |
The same split, written as the work itself:
| Native (admin) work | Developer work |
|---|---|
| Pipelines, workflows, snapshots, calendars, funnels, native Marketplace installs. | API v3 OAuth, webhooks, custom Marketplace apps, MCP tools, Voice AI that books into the CRM. |
| A snapshot that copies dashboard configuration into another sub-account. | A product that installs through HighLevel and has a life after the first import. |
| Zapier or Make for a simple, low-volume map with an acceptable delay. | Two systems editing the same contact, or volume where per-task pricing is the tax on growth. |
I am listed as both a HighLevel Certified Admin and a Verified Developer Partner. That is on the about page and in the footer. It does not mean every ticket needs code. It means when the account has hit the ceiling of native tools, the same person can read the CRM and write the integration.
A consultant who never logs in produces a roadmap. An admin who never leaves the UI produces a tidy account that still cannot talk to the other system. Most inbound work is a mix: the account is messy and the next requirement is outside the builders. That is why engagements start with a written look, not a retainer pitch.
When do you need a Verified Developer Partner?
You need a Verified Developer Partner when the next job is the platform layer: a Marketplace app, per-location OAuth, or an integration that has to survive as software, not another snapshot.
Verified Developer Partner is HighLevel's listing for developers who ship on the Marketplace, not a paid directory badge. Check the live partner page rather than a screenshot on someone's sales deck. Certified Admin is a separate credential for people who implement the product well.
If the work is still inside pipelines and workflows, a Certified Admin is the right hat. If the work is an app other locations will install, or Voice AI that must write into the same contact, look for the developer listing.
How does a developer engagement run?
A developer engagement runs as five steps that match how engagements work: you grant access, I audit, we stage a plan, we apply in slices, then I hand it back with you still owning the account.
- Access. You grant read access. You keep the HighLevel login and the data. Nothing is moved onto a private instance you do not control.
- Audit. A technical look under the bonnet: pipelines, fields, workflows, integrations and what is actually firing. The first slice is almost always a GoHighLevel account audit.
- Stage. The plan written up so you can review it, priced and prioritised, before anything is built. You sign off the phase.
- Apply. Built in slices you can test, each one validated before the next. Live customer data is not a sandbox.
- Hand back. Documented, with you still owning the sub-account and the data. Always.
If you take the written list and fix it yourself, that is a fine outcome. If the list says the next job is an OAuth app or a Marketplace install, that is when a developer is the right hire.
A typical developer week is unglamorous: reading webhook logs, checking which location an OAuth token still covers, writing the retry so a 429 does not drop the contact, and documenting the one custom field the next person will otherwise invent again. The client-facing artefact is a working booking, a clean sub-account, or a voice call that lands in the right pipeline.
I do not take over the login and disappear into a private build you cannot inspect. If the next slice needs a server beside HighLevel, you still own the CRM. The server is there so HighLevel does not have to pretend it is a general-purpose database.
What does this look like on a real account?
On a real account it looks like this: an agency already on HighLevel, a Zap creating a second contact for the same person, and a Voice AI brief that has to book into that same record, not a third one.
A snapshot will not merge those paths. An admin can tidy the pipeline. A developer maps one contact as the source of truth, then points the voice agent at it. No invented client name is required to see the shape: form plus Zap plus voice, one CRM, one record.
Adjectives are cheap. These are public write-ups of builds, anonymised where they need to be. None of them are composite covers pretending to be a product.
A Marketplace app for the front desk
You can deploy a clean CRM and still watch leads die because nobody on the floor owns the next call. FrontDesk Assist is a Marketplace-shaped app: a queue, a clock, a leaderboard. That is developer work sitting on top of HighLevel, not a clever snapshot.
A new sub-account from blank, without the checklist
The build is identical every time. The content inside it is different every time. Typing a hundred custom values by hand is how agencies lose a week. The provisioning console is the developer version of that job: server-side setup, then a human reviews the draft.
Off Zapier when per-task pricing stops making sense
Native connectors and Zapier are the right first move. At volume, the bill scales with success and the failure modes live in someone else's queue. Moving that automation onto self-hosted n8n is the point at which “admin who is good with Zapier” is no longer the role.
Agents that can use tools, not only chat
A prompt in a workflow AI step is admin work. An agent that calls MCP tools against HighLevel and a backend is developer work. The AI workbench notes are how that stack is actually wired on a desk, not a slide about “agentic AI”.
Voice on this domain, not a brochure claim
This site already runs a consent-gated ElevenLabs voice agent. It can search the pages, navigate, and book. That is the same pattern as client Voice AI deployments: the model is not the product. The product is the agent writing into HighLevel instead of leaving a voicemail you never return. If you want to try it, use the widget once performance cookies are allowed.
When do you not need a developer?
You do not need a developer when the whole fix lives inside HighLevel: tidy a pipeline, rewrite funnel copy, connect a native Marketplace integration, or build a snapshot for a new niche.
You also do not need a developer because a video said “API”. Zapier or Make is enough when the volume is low, the mapping is simple, and nobody minds a delay. What usually looks like a developer ticket and is not: renaming fields, splitting one pipeline into two, or turning off a workflow that has been emailing the dead list since 2023.
- Get audit access. Send the form and grant read-only. Do not hand over the login as a hostage.
- Do not add another Zap while you wait. Another create-path is how a recoverable account becomes a rebuild.
- Decide from the written list. Hire a developer only for the slices that are not inside the dashboard.
Skipping the first step is how people pay developer rates for a tag rename.
FAQ
Is Zapier enough instead of a developer?
When the mapping is simple, the volume is modest, and a delay is acceptable. It stops being enough when two systems edit the same record, when per-task pricing becomes the tax on growth, or when the failure has to be yours to see and fix.
Should I install a snapshot or build a Marketplace app?
A snapshot copies dashboard configuration into another sub-account. A Marketplace app is a product that installs through HighLevel, with OAuth, its own UI, and a life after the first import. Use a snapshot for a repeatable native setup. Use an app when the job sits beside HighLevel or has to be maintained as software.
What is the difference between a PIT and OAuth?
A Private Integration Token is a long-lived key for one location, useful for a single-account integration you control. OAuth is the Marketplace install path: the client grants scoped access per location, and tokens can be refreshed without sharing a password. Current work is HighLevel API v3 either way.
Who holds the sub-account?
You do. You keep the HighLevel sub-account and the data throughout. I stage the plan, then apply. Nothing is quoted as a hostage against a login you do not control.
Can I skip the audit and go straight to a build?
Only if you already have a written map of what is live. Most inbound work is a messy account plus a requirement the menus cannot do. Starting with the form below is how we avoid paying developer rates for a tag rename.
Related reading
Signs your GoHighLevel account needs an audit · Hire a GoHighLevel developer · All articles
Next step
If this is the job, say so
Thirty minutes is usually enough to tell whether it is a developer ticket or an audit. You keep the account either way.
Not sure yet? Start with the free audit.
Gareth Richardson
HighLevel Verified Developer Partner and Certified Admin.
I audit and rescue HighLevel accounts, then build the slices the menus cannot do: API v3 integrations, Marketplace apps, and Voice AI that writes into the same CRM. You keep the sub-account and the data throughout. More on the about page.