Why is my GoHighLevel inbound webhook not firing?
Usually one of five things: the workflow is not published, the webhook URL in the sending system is not the one GoHighLevel generated, the sender is not sending the method the trigger expects, the trigger's filters exclude the record, or the sender never sends at all. Check them in that order, because the first two cause most cases.
Start with a fact that changes how you troubleshoot: a webhook that does not fire leaves almost no trace on the GoHighLevel side. Nothing appears in the workflow, so you have to prove each link in the chain before you blame the trigger.
What is confirmed and what is not. GoHighLevel's own API article points to its developer documentation for webhook events, and the help article we could reach does not describe the inbound trigger's behaviour. The steps below combine the trigger setup shown in third-party guides with general webhook troubleshooting. Check each one on your own account.
Did the sender send anything at all?
Check the sending system's own log first. If it shows no request, or a failed one, the problem is in the sender, and GoHighLevel will never see the event.
Most sending tools record each webhook call with its status code and response. A 404 means the URL is wrong. A 405 or similar means the method is wrong. A timeout means the destination did not answer in time. Fix the error the sender reports before you touch the workflow.
Is the URL the one GoHighLevel generated?
The URL must be copied from the Inbound Webhook trigger in the same sub-account as the workflow. A URL copied from another sub-account, an older workflow or a test screenshot will not match.
Sub-accounts are separate, so a webhook created in one will never fire a workflow in another. If you duplicated a workflow or moved it, check that the sender uses the URL of the copy that is now live, not the original.
Is the workflow published?
A draft workflow does not run for live events. Publish it, then send a fresh test, because a test sent before publishing tells you nothing about the live path.
This is the most common cause in practice. The workflow looks finished in the editor, the sender reports success, and nothing happens because the workflow was never switched on.
Does the method match what the trigger expects?
Compare the method the sender uses with the one the trigger accepts. Third-party guides describe the inbound trigger as accepting POST, GET or PUT, so a sender that sends DELETE or PATCH will not match it.
Set the sender to POST if you control it. If the sender only offers a different method, check the trigger's current options on your account, because the list can change.
Do the trigger's filters allow this contact?
Filters and re-entry settings can stop a contact that is valid. Check the enrollment history for the contact: if it shows the entry, the trigger fired and the problem is later in the workflow.
Common causes are a filter that requires a tag the sender does not add, a re-entry setting that blocks a contact who already went through the workflow, and a condition on a field that the sender renamed. Test with a fresh contact, not one that already entered the workflow.
What should you do if the checks pass?
Read the workflow's execution details for the request, then compare the data the sender sent with the fields the workflow expects. A trigger that fires with the wrong data looks like a trigger that does not fire.
If the request arrives but the contact is wrong or incomplete, the cause is field mapping or a renamed field, not the webhook itself. Fix the mapping, send a fresh test, and record which field changed so the next person can find it quickly.
When should you get help with a webhook?
Get help when a webhook has stopped and you cannot see the sender's logs, when more than one flow depends on it, or when the data carries personal or patient information.
A short fix is often a copied URL or a published workflow. A flow that has been silent for a week, with leads lost in the gap, needs a proper audit: every webhook mapped, tested and alerted. Our GoHighLevel setup service includes that testing, and the GoHighLevel automation page explains how workflows are built. For connecting a tool that has no native GoHighLevel integration, read how GoHighLevel inbound webhooks work. If the sender is an n8n or Zapier flow, the test and production URL question and the Catch Hook question cover the same checks from their side.
Related questions and services
- How GoHighLevel inbound webhooks work, step by step
- What is the difference between n8n's test and production webhook URLs?
- What is a Zapier Catch Hook?
- How do you set up an n8n webhook?
- GoHighLevel automation
- GoHighLevel setup service
Sources and further reading
- GoHighLevel developer documentation (webhook events; the help article we could reach did not describe the inbound trigger, checked 2026-10-04)
- Third-party guide: GoHighLevel inbound webhook trigger (trigger setup and accepted methods; not an official source)
Screens and trigger options change. Where this page differs from GoHighLevel's current documentation, follow the documentation.
