The work
What this actually involves
Connecting an API is the easy part. The work is what holds it up: authentication that survives a token rotation, retries that do not duplicate writes, and a reconciliation step for when two sources disagree.
I build MCP servers so AI agents can use your systems as tools, and ordinary integrations for everything that does not need an agent.
Included
What you get
Your systems exposed as tools an agent can call, with scoped permissions and structured returns.
MCP servers
Your systems exposed as tools an agent can call, with scoped permissions and structured returns.
Legacy API to API v3 OAuth
Migrations carried out without interrupting accounts that are live and billing.
Middleware
The bit between two systems that neither vendor will own: queues, transforms, retries, dead letters.
Reconciliation
When sources conflict, the conflict is surfaced rather than silently resolved.
Hire me when
Signals this is the right piece of work
An AI agent needs to reach a system that has no integration
You are moving a live account onto API v3 OAuth and cannot afford downtime
Two systems drift out of sync and nobody can explain which one is right
A legacy database holds the data the rest of the stack needs
Webhooks fire twice, or stop firing, and the failure is silent
You need the integration documented so it is not a black box after handover
The problem
HighLevel is excellent until it has to talk to something else
Every serious HighLevel account eventually hits the same wall. The platform does ninety per cent of what the business needs, and the remaining ten per cent lives somewhere else: a loan origination system, a practice management system, a warehouse database, a bespoke internal tool somebody built in 2014 and nobody has touched since.
At that point most people do one of three things. They rekey data by hand and call it a process. They wire it together with Zapier and watch the bill grow faster than the revenue behind it. Or they are told it cannot be done, usually by someone whose skill set stops at the native builders.
The fourth option is to build the integration properly. That is this piece of work.
What gets built
Four things, depending on what you are connecting
Where the other system has a decent API. HighLevel API v3, per-location OAuth, token refresh handled properly so it does not silently expire at three in the morning.
Direct API integration
Where the other system has a decent API. HighLevel API v3, per-location OAuth, token refresh handled properly so it does not silently expire at three in the morning.
Webhook bridges
Where the API is limited or expensive. One endpoint sending, one listening, authenticated headers, and idempotency so a retry does not create the record twice.
MCP servers
So an AI agent can actually reach your systems and do work in them, rather than just describing what it would do if it could.
Middleware you can see into
Self-hosted, logged, with a queue you can inspect. When something fails at two in the morning you want a log line, not a shrug.
MCP
Model Context Protocol, in plain terms
An MCP server is the layer that lets an AI model use your systems as tools rather than guess at them. Instead of an assistant that can talk about your CRM, you get one that can read a contact, check a calendar, move an opportunity and write back a note, with permissions and an audit trail.
This matters more each month. The useful version of AI in a business is not a chatbot bolted onto a website, it is an agent with real access to real systems and clear boundaries around what it may do. MCP is how that access gets granted safely.
Almost nobody in the HighLevel ecosystem builds these commercially yet. The work exists mostly as open-source repositories and documentation. If you are trying to give an agent genuine reach into a HighLevel account and the systems around it, there are very few people to call.
Worked example
Replacing per-task pricing with owned infrastructure
A client was running their operation on Zapier. Per-task pricing works until volume arrives, at which point the bill grows faster than the revenue producing it.
Every Zap was catalogued first, by trigger, by monthly volume and by actual business purpose. That exercise alone is usually revealing. Several workflows turned out to be duplicates of each other, and several more had been built for a process the business had since stopped doing. Those were consolidated or deleted rather than rebuilt.
What remained was rebuilt on self-hosted n8n, run in parallel with the existing Zaps until the outputs matched exactly, and only then cut over. No big-bang migration, no weekend where nothing works.
The result was a lower cost per run, headroom to scale without a pricing cliff, and infrastructure the client owns rather than rents.
Boundaries
What this deliberately does not include
If the system you are connecting to has no API and no webhooks, I will tell you that on the call rather than after the invoice. Sometimes the honest answer is parsing their notification emails, which is ugly but works.
Fixing the other vendor's API
If the system you are connecting to has no API and no webhooks, I will tell you that on the call rather than after the invoice. Sometimes the honest answer is parsing their notification emails, which is ugly but works.
Unlimited scope creep
Integrations attract requests. The build is scoped to defined endpoints and defined fields, and anything beyond that is quoted separately rather than absorbed silently.
Running your business logic for you
I build and document the integration. Ongoing operation sits with you unless you want a retainer, in which case say so at the start.
Common questions
Questions people ask before booking
Can you integrate GoHighLevel with a system that has no public API?
Often, yes. If there are webhooks, a bridge works well. If there is neither, structured notification emails or SMS from the other system can be parsed as a fallback. It is not elegant, but it is reliable and considerably cheaper than the alternative. I will tell you which of the three applies before quoting.
What is an MCP server and do I actually need one?
It is the layer that lets an AI agent use your systems as tools with permissions and an audit trail, rather than just describing them. You need one if you want an agent to genuinely do work in your CRM. You do not need one for a website chatbot.
How do you stop webhooks firing twice and creating duplicate records?
Idempotency keys and a deduplication window, so a retried delivery updates the existing record instead of creating a second one. This is the single most common defect I find in integrations built by other people.
Who owns the integration when it is finished?
You do. It runs on your infrastructure or your account, the credentials are yours, and it is documented so another developer can pick it up. There is no dependency on me continuing to be involved.
What happens when HighLevel changes their API?
Breaking changes are announced in advance. On a retainer I check them against your build before they land. Without one, you find out when something stops working, which is the more expensive way to discover it.
Do you work with n8n, Make or Zapier?
All three, and frequently migrating away from the last two onto self-hosted n8n when per-task pricing stops making sense. The migration runs in parallel until outputs match before anything is cut over.
Start here
Start with the audit
A written architecture record and a staged plan, useful whether or not I build the rest.