The Webhook Bridge: a GoHighLevel custom webhook setup for service businesses

This is the guide from the Cortex video on the Webhook Bridge. It follows the same three steps as the video:

1. The webhook step. You add a Custom Webhook action to a GoHighLevel workflow, so you decide exactly which events leave.
2. The check. The agent looks up that customer in your field software, such as Jobber, ServiceTitan or Housecall Pro.
3. The approval. The agent drafts the next text, and someone in your office approves it before it goes.

The reason for all three is simple. GoHighLevel knows what happened in GoHighLevel. It does not know that your crew finished the job in your field software, so without a bridge your CRM keeps treating a finished customer like a fresh lead.

Check what GoHighLevel already does

Before building anything, look at the built-in tools. A weekly roundup from GHL Experts, a partner community rather than HighLevel itself, describes an AI Agent action inside Workflows with 11 prebuilt templates, including form lead follow-up, plus a redesigned Voice AI builder. If your need sits entirely inside GoHighLevel, use those. The bridge is for the space between GoHighLevel and the software where your jobs live.

What you need first

• Admin access to the GoHighLevel sub-account, so you can edit workflows.
• An address for the agent to receive events (your builder gives you this) and a secret token for the request header.
• A field-software account that allows API access for the lookup.
• One person in the office who reviews the drafts each day.
• A short list of the events you care about. Start with two.

Step 1, the webhook step

HighLevel's help center says the Custom Webhook workflow action can send a GET, POST, PUT or DELETE request to any URL, with bearer token, API key, basic auth or OAuth2. The workflow sends it when a contact reaches that step, so the workflow itself is your filter.

A setup that works for most service businesses:

1. Create a workflow named after its job, for example "Bridge: stage changed".
2. Trigger: Pipeline stage changed, filtered to the pipeline your sales team uses.
3. Add the Custom Webhook action. Method POST. The URL your builder gave you.
4. Authentication: a bearer token in the header. The help article notes HighLevel does not offer a static IP to allow-list, so the receiving side has to trust the header, not the address.
5. Body: the contact ID, name, phone, email, the opportunity ID and the new stage. Nothing else.
6. Publish, then move one test contact through the stage and confirm the agent received it.

The article does not describe automatic retries, so ask your builder what happens when the agent is down for an hour. The honest answer is usually a nightly catch-up check, and that is fine.

Which events to send, and which to keep

Event	Send it?	What the agent does with it
New lead from a form or call	Yes	Checks whether this phone number already has an open or recent job, so a repeat customer is not treated as new
Pipeline stage changed	Yes	Checks the job's status in field software and drafts the matching text
Appointment booked	Maybe	Confirms the visit exists in field software too
Tag added	Only for a tag with one clear meaning	Depends on the tag
Every message received	No	Too noisy; leave conversations to your team and GoHighLevel's own tools

Sending fewer events is the point. Each event you send is something the agent has to act on correctly.

Step 2, the check

When an event arrives, the agent looks the customer up in your field software and asks one question: does the CRM's view of this person match reality? Match on phone number and service address together, because names repeat.

If your field software is Jobber, its developer docs say webhooks must be answered within one second and may be disabled if responses are slow or erroring. If you also want job events flowing the other way, the receiving side has to acknowledge fast and do the real work afterwards.

Step 3, the approval

The draft goes somewhere a person sees it before it reaches the customer. Two examples of drafts the agent might write. Names are examples.

Hi Carla, glad the new water heater is in. If anything seems off this week, just text us here. Bluewater

Hi Tom, we have you down for Thursday's drain visit. Reply here if the time needs to change.

The approver checks three things: the right person, the right job and nothing in the account that says to call instead. Keep approvals on for every message at first. We explain the reasons in human-in-the-loop AI.

The limits that shape the build

HighLevel's rate limits page says an OAuth app gets 100 requests per 10 seconds and 200,000 per day, counted per sub-account or agency. That is plenty for an agent that waits for events. It is not enough for an agent that checks every contact one by one, and a Supergood review notes there is no bulk export, so pulling a whole account means paging through it. Let the workflow push events instead of having the agent poll.

The same review says OAuth access tokens last about 24 hours and refresh tokens rotate, so a Marketplace app must save the new refresh token every time. For a single sub-account you own, it says a Private Integration Token is the simpler option. It also says some features in the app are not in the API at all, and that the documentation lags new releases, so someone should own the connection after launch.

How to tell the bridge works

• A test contact moved through your stage shows up at the agent within a minute.
• A repeat customer who fills in a form is recognised as a repeat customer.
• No customer gets a "thanks for your interest" text after the job is done.
• Your approver clears the drafts in a few minutes a day, and edits fewer of them each week.

If you want the background on how agents work around GoHighLevel, read how an AI agent for GoHighLevel works. If you would like someone to map where your CRM and field software disagree, your free AI Operations Audit covers it.