How to Fix GoHighLevel Workflow Webhook Not Firing or Sending Data

Your workflow triggers, but your backend never receives the request—or worse, it catches an empty JSON body with missing fields. When a GoHighLevel webhook fails silently, it breaks sync pipelines across Zapier, Make, custom Node microservices, and client databases.

I’ve spent plenty of late nights debugging this across agency sub-accounts. In almost every case, the breakdown comes down to four culprits: execution log mismatches, unmapped custom field keys, SSL timeout drops, or trigger re-entry blocks. Here is how to trace the exact failure point, inspect raw payloads, and fix your outbound webhook action.

Step 1: Check Workflow Execution Logs for Silent Halts

Before you mess with webhook URLs or tweak your receiver’s code, look at the contact’s actual execution path in GHL. Half the time, the contact simply got diverted before reaching the webhook node.

Open your workflow builder and click Execution Logs in the top header. Filter by your test contact’s email.

• Skipped: The contact hit an If/Else branch that bypassed your webhook entirely.
• Waiting: A Wait step earlier in the flow is pausing execution. The contact hasn’t reached the webhook step yet.
• Failed: GHL attempted the HTTP request, but your server returned a non-2xx status code or timed out (usually after 10–15 seconds).
• Finished: GHL sent the payload and got a 200 OK or 201 Created back.

If the step is marked Failed, click into the log details. GHL will display the exact HTTP status code returned by your endpoint (like 400 Bad Request, 401 Unauthorized, or 500 Internal Server Error).

Step 2: Verify Workflow Status and Allow Re-Entry Rules

If the webhook isn’t firing at all, your workflow might be dropping the trigger event silently.

First, check the top-right status toggle. If it’s set to Draft instead of Publish, clicks on “Test Action” inside the builder will work, but real contact events won’t trigger the flow.

Second, head into Settings inside the workflow builder and check Allow Re-entry.

When you run repeated tests with the same dummy contact, GHL ignores trigger events after the first run unless re-entry is turned on. If it’s disabled, GHL marks the contact as already processed and won’t enroll them again.

If your workflow handles API syncs or recurring updates, turn on Allow Re-entry. Also keep an eye on Stop on Response: when active, an incoming SMS or email reply from that contact will instantly pull them out of the workflow before reaching any downstream webhook nodes.

Step 3: Route Payloads to Webhook.site to Isolate the Receiver

When you’re not sure whether GHL is failing to send or your server is failing to parse, isolate the receiver completely. I always point GHL at a temporary test URL first to inspect the raw headers and body.

Open Webhook.site in a new tab and grab your unique target URL.

In your GHL workflow, swap your webhook URL with the Webhook.site address, save, and publish.

Trigger the workflow using your test contact. Then check Webhook.site immediately to view the incoming request:

{ "contact_id": "q8WkXv9L2Zp0RtY1", "first_name": "Fahim", "last_name": "Reza", "email": "test@isitdev.com", "phone": "+15550192834", "tags": "lead, newsletter, website-form", "custom_data": { "account_tier": "Enterprise", "monthly_spend": "2500" }
}

If Webhook.site gets the payload instantly, GHL isn’t the problem. The issue lives on your receiving end—strict CORS policies, dropped headers, unhandled SSL handshakes, or a JSON parsing exception crashing your script before sending a response.

Step 4: Fix Empty Payload Issues and Missing Custom Fields

Another common headache: the webhook fires, but custom fields arrive blank or get stripped from the JSON payload entirely.

HighLevel structures outbound payloads differently depending on the action type. The standard Webhook action sends a default contact object. If a contact has empty values for custom fields, GHL either sends them as null or leaves the keys out completely.

If your receiving API expects strict schemas without missing properties, empty fields will break your parsing logic. If you’re using merge tags in a custom payload builder, make sure you configure fallbacks. Check out our guide on how to set fallback default values for merge fields in GoHighLevel to keep null keys from crashing your scripts.

Also, verify that the contact record actually holds data for those fields before the webhook node runs. If an external form is updating custom fields, drop a quick 1-minute Wait step before the webhook action so GHL has time to finish its database writes.

Step 5: Resolve 400 Bad Request and Custom Data JSON Syntax Errors

When using the Custom Webhook action, you can build raw JSON bodies or query parameters manually. A single trailing comma or unescaped double quote will cause GHL or your receiving server to throw a 400 Bad Request.

Here is a properly structured custom POST body using GHL merge tags:

{ "event": "contact_updated", "location_id": "{{location.id}}", "contact": { "id": "{{contact.id}}", "name": "{{contact.name}}", "email": "{{contact.email}}", "phone": "{{contact.phone}}" }, "timestamp": "{{workflow.execution_time}}"
}

If you need to verify your sub-account identifiers inside payload bodies, read our tutorial on finding your sub-account Location ID in GoHighLevel.

Watch out for merge tags that pull in multiline notes or user-entered text containing double quotes (like address fields or comments). When GHL injects unescaped quotes or raw newlines into a raw JSON template, it breaks the JSON structure and triggers an immediate HTTP 400 error.

Step 6: Handle Authentication Headers and SSL Certificate Drops

If your endpoint requires an API key or Bearer token, unauthenticated requests will immediately fail with a 401 Unauthorized or 403 Forbidden in your execution logs.

GHL’s standard Webhook action doesn’t support custom headers. To pass auth tokens, switch to the Custom Webhook action and supply your credentials under Headers:

Authorization = Bearer your_secret_api_token_here
Content-Type = application/json
X-Custom-Source = HighLevel-Workflow

For a complete breakdown of Bearer tokens, Basic Auth, and custom key pairs, see our guide on sending authenticated webhooks with custom headers in GoHighLevel.

Also check your SSL setup. GHL enforces strict TLS checks. If your server uses a self-signed cert, an expired certificate, or an incomplete intermediate CA chain, GHL drops the connection during the TLS handshake without retrying.

Step 7: Inbound Webhook Triggers vs Outbound Webhook Actions

Make sure you haven’t mixed up an Inbound Webhook Trigger with an Outbound Webhook Action. They do opposite things:

• Inbound Webhook Trigger (Premium Action): Gives you a GHL URL to listen for data from external platforms (Stripe, Shopify, web forms). GHL listens for incoming requests to start the workflow. See the GoHighLevel Help Center for inbound payload mapping docs.
• Outbound Webhook Action: Runs as a step inside your workflow to push data out of GHL to external APIs or middleware.

If your workflow relies on an inbound trigger and isn’t starting, verify your field mapping. You must map at least an Email or Phone field so GHL can identify or create the contact record.

To confirm that your fields are resolving properly before reaching the webhook node, check our guide on how to insert and test merge fields in GoHighLevel.

Frequently Asked Questions

Why does my webhook test work in the builder, but live triggers fail?

The builder’s “Test Action” button sends mock dummy data. In production, the live contact running through the flow might be missing required fields (like a phone number or email), causing your receiver to reject the payload with a validation error.

How many times does GoHighLevel retry a failed webhook?

Standard GHL workflow actions don’t run automated exponential backoff retries. If your server returns a 500 error or times out after 15 seconds, GHL marks the step as Failed and moves the contact to the next action unless you’ve set up explicit error-handling branches.

Can I send GET requests with GoHighLevel webhooks?

The standard Webhook action only dispatches POST requests with the default contact payload. If your target API requires a GET request with query parameters (e.g., https://api.example.com/sync?email=user@test.com), switch to the Custom Webhook action and change the Method to GET.

Does HighLevel support webhooks over HTTP, or only HTTPS?

GHL requires secure HTTPS endpoints for all outbound webhooks. Any request pointed at a plain http:// address fails immediately.

Next Steps for Rock-Solid Automation Pipelines

Once your webhook is dispatching clean JSON, make sure your receiving endpoint responds with a 200 OK within 3 seconds. If your backend needs to perform heavy database queries or chained API calls, ingest the payload into a background queue (like Redis or AWS SQS) and return an immediate 200 back to HighLevel.

If your workflows depend on booking events, ensure calendar availability settings aren’t blocking contacts from entering the workflow in the first place. See our guide on fixing GoHighLevel calendars not showing available times to keep your scheduling triggers reliable.