The CRM sends an event.
n8n has to trust it first.

From a test event to a working receiver.

Start with an n8n Webhook node and select the HTTP method used by the sender. Listen for a test event, configure a HighLevel workflow action with that test URL, and use a test contact to inspect the body and headers.

Agree the payload and caller verification before adding a side effect. Publish the n8n workflow, replace the test address with its Production URL in HighLevel, then verify a delivery in n8n’s execution history. For app webhooks, use the app subscription and verification process instead of assuming workflow action behavior.

The body below is fictional custom data you could configure for a workflow action. It is not a HighLevel event schema or a client export. Map from the actual delivery from your account.

{
  "event_id": "demo-001",
  "contact_id": "example-contact",
  "stage": "new",
  "schema_version": 1
}

Need this connected to your CRM?

An integration review maps the sender, receiver, fields, failure states and next owner. You receive a failure map, prioritized fixes and a proposed implementation scope before agreeing a build.

Explore GoHighLevel integration services or use the inquiry button to discuss the workflow.

Know which HighLevel route is sending.

HighLevel can call n8n from two places. A workflow inside the CRM can include a webhook action that posts to a URL when the workflow reaches that step. A Marketplace app can subscribe to platform events for the locations that installed it and receive deliveries without any workflow being involved.

The two routes send different payloads and carry different guarantees. The workflow action sends the contact the workflow is running for, plus whatever custom data the action is configured with. The app route sends event objects for things like contact updates or inbound messages. Which events exist, and what each one contains, depends on the current platform version and on the scopes the app was granted. The HighLevel developer documentation is the reference for the app route.

For most small integrations I start with the workflow action. It needs no app review, and the trigger conditions live in the same builder the team already uses. I move to app webhooks when the integration needs events that no workflow trigger exposes, or when it must serve many locations at once.

Look at what arrives before designing anything.

The documented payload and the delivered payload are not always the same object. Field names change between versions, custom values arrive under keys you did not expect, and empty fields may be missing rather than null. I never map from documentation alone.

Create the n8n workflow with a single Webhook node, select Listen for Test Event, and fire the HighLevel workflow against a test contact. The node shows the headers, query, and body it received. Save that sample somewhere the team can find it. It becomes the contract the rest of the workflow is built against.

Repeat the test with a contact that has empty fields, an unusual phone format, and a name with accented characters. The differences between those three samples tell you more than any schema page.

Use the test URL to build and the production URL to run.

The n8n Webhook node exposes two URLs. The test URL works only while the editor is listening for a test event, and it shows the data inline. The production URL is registered when the workflow is published, and its executions are recorded in the execution list rather than shown in the editor. See the Webhook node documentation.

Put the test URL in HighLevel while you build, then swap to the production URL once the workflow is active. If a delivery seems to vanish, the usual cause is a workflow that was never activated, or a HighLevel action still pointing at the test URL after the editor stopped listening.

Keep the HTTP method explicit. The workflow action posts, so set the node to accept only POST. An accidental browser visit then gets a refusal instead of creating a stray execution. The Ignore Bots option filters link previewers and crawlers for the same reason.

Decide when the response goes back.

The Webhook node can respond immediately with a fixed message, respond when the last node finishes, or hand the response to a Respond to Webhook node. Each choice changes what HighLevel sees and how long the sender waits.

For a notification that needs no answer, respond immediately. HighLevel gets a quick 200, and the rest of the workflow runs on its own time. That decouples the sender from your processing, which matters when the workflow calls slow external systems.

Respond after processing only when the caller needs a result from n8n, and keep the work before the response short. A sender that waits too long may treat the delivery as failed and, depending on its retry policy, send it again. I treat any sender timeout as an assumption to test, not a number to look up.

Assume every event can arrive twice.

Retries, a workflow that runs again for the same contact, and human edits can all produce a second delivery for the same event. Whether the platform retries a failed delivery, and how often, depends on the route and on the current behavior of the platform. I design for repeats regardless.

Derive a stable event key from the payload: the contact id, the workflow or event name, and an event id or timestamp when one is present. Claim the action atomically before any side effect. A separate lookup and insert can race; choose storage that enforces the required uniqueness and ownership. Hold uncertain delivery outcomes for reconciliation. The duplicate actions guide covers the full pattern, including what to do when a response never comes back.

Responding immediately does not remove the need for this check. It only shortens the window in which a retry could arrive while the first execution is still running.

Check that the caller is really HighLevel.

A webhook URL is a public endpoint. Anyone who learns it can post to it. Marketplace app deliveries carry a signature that can be verified against a key HighLevel publishes; confirm the header name and the verification steps in the current app documentation before relying on it. The workflow action does not sign its requests in the accounts I have worked with, so that check has to be built by you.

The simplest control is a secret. If the account’s webhook action supports custom headers, send a shared secret in a header and use the Webhook node’s Header Auth credential to reject anything without it. If custom headers are not available, a long random segment in the URL path is the fallback. It is weaker, because URLs end up in logs, so rotate it when staff change.

n8n also offers an IP allowlist on the Webhook node. I do not rely on it for HighLevel, because the sending addresses are not something I can promise will stay fixed. Use it as a second layer when you control the sender, not as the only gate.

Log the raw payload before you parse it.

Parsing is where webhook workflows break. A missing field or a new nesting level throws an expression error, and the delivery is gone unless something recorded it first. After verifying the caller, preserve the fields needed for recovery and the received time before mapping. Redact authentication secrets and unnecessary personal data before logging, restrict access, and define retention. Keep a separate safe copy for debugging when the exact received bytes are needed for signature verification.

Enable the Raw Body option when you need the exact bytes rather than the parsed object. That matters for signature checks, which must run against the original body, and for payloads that use unusual content types.

With the raw record in place, a failed parse becomes something you can replay. Fix the mapping, then run the stored payloads through the corrected workflow. Without it, you are asking the team to trigger the HighLevel workflow again for every contact that failed.

Run this list before going live.

Workflow is active

The production URL only responds once the workflow is published. Confirm the HighLevel action points at the production URL, not the test URL.

Method restricted

The Webhook node accepts only the method HighLevel sends. Ignore Bots is on.

Caller verified

A header secret or a signature check rejects unknown callers. The secret lives in a credential, not in the workflow JSON.

Raw payload stored

After caller verification, store the required event fields and time with credentials and unnecessary personal data redacted. Define access and retention for the log.

Duplicate key checked

An atomic claim or provider idempotency controls duplicate attempts; uncertain outcomes are reconciled.

Response mode chosen

Immediate for notifications. After processing only when the caller needs a result and the work is short.

Error workflow set

An Error Trigger workflow records failed executions so a bad payload is visible the same day.

Three samples saved

Test deliveries with a full, a sparse, and an unusual contact are saved next to the workflow as the reference contract.

Questions.