Two directions
The Inbound Webhook trigger receives data. When you add it to a workflow, HighLevel generates a unique URL for that trigger. The URL captures POST, GET, and PUT requests, and you map the incoming data to workflow fields.
The Webhook action sends data. When a contact reaches that step, HighLevel packages data about the contact and the triggering event into a payload and sends it to the URL you chose. A second action, Custom Webhook, does the same with more control over the request.
Receiving data with the inbound trigger
HighLevel's article does not spell out how it matches incoming data to an existing contact. Test a request for a contact who already exists before you go live, and check whether you get a duplicate or an update.
- Add the Inbound Webhook trigger to a workflow and copy the URL it generates.
- In the other app, send JSON to that URL.
- Send a test request so HighLevel captures a sample.
- Map the fields in the sample to the workflow fields you want to fill.
Sending data with the Webhook action
The standard action sends with POST by default. The payload carries the contact name, email, phone, address, tags, and custom fields. It adds objects such as appointments, opportunities, and invoices only when the workflow trigger relates to them, so an appointment field will be empty in a workflow that a form submission started.
HighLevel states that the webhook action cannot send images or files.
When to use Custom Webhook
HighLevel says to use Custom Webhook when you need advanced authentication and flexible request building, and the standard Webhook action for simpler patterns.
- It supports GET, POST, PUT, and DELETE requests.
- It offers five authorization options: bearer token, API key, basic auth, OAuth2, and none with custom headers.
- It accepts JSON bodies, including nested objects and arrays, and form encoded bodies when you set the Content-Type header.
- It fills headers, query parameters, and body fields with contact values such as the contact ID, email, and phone.
- It can capture the response, which you review in Execution Logs, if your account offers it.
Test before you publish
- Run Test Workflow with a sample contact.
- Send the call to a request inspector such as webhook.site or Postman first, so you can read the exact payload.
- Check the URL, method, Content-Type, and credentials.
- Read the Execution Logs after each test.
Mistakes that break webhooks
- Putting secrets in query strings. HighLevel advises against it unless the provider requires it.
- Expecting data the trigger does not carry. The payload depends on the trigger.
- Trying to send a file. The action cannot.
- Assuming HighLevel retries a failed call. The help articles do not describe retries, so log every request on the receiving side and reconcile the gaps.
- Skipping the premium check. HighLevel labels some webhook triggers and actions as premium in its help center, so check the rates in your account before a workflow fires them thousands of times.
Common questions
Can GoHighLevel receive data from other apps?
Yes. The Inbound Webhook trigger gives each workflow its own URL, and another app can send a request to it to start the workflow.
Which HTTP methods does Custom Webhook support?
GET, POST, PUT, and DELETE.
Can a webhook send a file or image?
No. HighLevel states that the webhook action cannot send images or files. Send a link to the file instead.
When should I hire a developer for webhooks?
When the receiving system needs authentication, data cleanup, or reliable delivery that a single workflow step cannot give you. Our integration work covers that.