Webhook Nodes

Webhook nodes let a funnel send data to an external system while the visitor moves through the funnel.

Think of them as outbound automation points. A visitor reaches the webhook node, FunnelFlux sends an HTTP webhook payload to the selected destination, and the funnel continues to the next connected node.

Use webhook nodes when you want FunnelFlux routing to trigger something outside FunnelFlux.

What webhook nodes are useful for

Webhook nodes are useful when you want to:

• send lead or visitor context to a CRM
• trigger a Make.com, Zapier, n8n, Pipedream, or custom workflow
• notify an internal system when a visitor reaches a key funnel step
• pass action form data from a lander into another platform
• connect funnel movement to tools that do not have a native FunnelFlux integration

For example, you might use a webhook node after a form-submit action so that Make or Zapier receives the visitor's submitted email, phone, or other form fields.

Webhook configs vs webhook nodes

Webhook configs are reusable destination settings. They define where the webhook should be sent, such as a Make webhook URL, Zapier catch-hook URL, or custom endpoint.

Webhook nodes are the places inside a funnel where those configs are used.

This means you can create one webhook config, then use it in one or more funnels. You can also attach multiple webhook configs to one webhook node when you want the same funnel step to notify several systems.

Note: you can also trigger webhook nodes "on actions" much like conversions and custom events:

In some cases such as form submits, you may find this location more convenient.

Normal webhook nodes will try to source and send the most recent action data (from a page click) at all times. Executing on-action like above will guarantee this as it happens at the action level.

Fundamentally there will be no difference in the webhook payload here -- the main difference will be the webhook appearing as a node in your journey data.

Basic setup

The usual setup is:

1. Create the receiving webhook in your external tool, such as Make or Zapier
2. Copy the webhook URL from that tool
3. Create a webhook config in FunnelFlux using that URL
4. Add a webhook node to your funnel
5. Select the webhook config in the node settings
6. Connect the webhook node to the next step in your funnel
7. Test the funnel yourself and confirm the external tool receives the webhook

Webhook nodes are passthrough nodes. They do not contain pages, rotate traffic, or make routing decisions by themselves.

Testing with Make or Zapier

Most automation tools have a webhook listener or test mode.

In Zapier, start the catch-hook test step first, then navigate your FunnelFlux funnel so your traverse the webhook node.

In Make.com, run the scenario or webhook listener first, then test the FunnelFlux path that should hit the webhook node.

This is usually the easiest way to confirm everything is wired correctly. The external tool needs to be listening before you test, otherwise it may not show the payload you expected.

From there, you can design your automation. If you are using AI to build code around these webhooks, see our schema docs here that describe the payloads.

What data gets sent

Webhook node payloads include funnel and visitor context where available.

Depending on the route and how the visitor reached the node, this can include:

• visitor/session identifiers
• current funnel and node information
• traffic source information
• tracking fields captured from the entrance URL
• current URL/token buffer values
• action data from form submits or action requests
• visitor tags present when the webhook was built

The exact payload is technical, so we will not document every field here. For schema details, see the FunnelFlux API documentation:

FunnelFlux API documentation

Action data and forms

Webhook nodes become especially useful after form submits.

If a visitor submits action data on a lander, FunnelFlux can include that action data in the webhook payload when the visitor reaches the webhook node. This lets you pass form values into tools like Make, Zapier, CRMs, Slack notifications, or your own backend.

For example, a form submit could collect an email address and first name, then route through a webhook node that sends those values to a Make scenario.

This allows you to use your own custom forms on pages, push the data to FunnelFlux, and let some other automation handle adding it to a CRM -- giving you complete freedom in your page design. No more clunky email system embeds.

Note we support multiple formats of POST submitted form data, as documented in our link earlier.

Regarding privacy, we do not store/log the specific payloads going through webhook nodes, but do log the responses -- you can see these in the Logs > Webhook Logs section.

Delivery behavior

Webhook delivery happens in the background.

The visitor should continue through the funnel even if the external service is slow or the webhook delivery fails. Delivery failures should be checked in webhook logs rather than treated as something the visitor sees in the redirect.

This is important: do not use a webhook node when the external system must return a decision before the visitor can continue. Webhook nodes are for notifying external systems, not for making live routing decisions.

Our future feature, middleware nodes, will enable this approach.

Common mistakes

Do not paste a normal web page URL as your webhook URL. Use the actual webhook/catch-hook URL provided by the external tool.

Do not test Zapier or Make after the fact and expect old webhook attempts to appear. Start the listener first, then trigger the funnel.

Do not put sensitive data into tracking URLs unless you are comfortable sending that data through your tracking flow and connected tools.

Do not use webhook nodes for conversion tracking if a normal postback, JavaScript conversion, or API upload is the right tool. Webhook nodes are for outbound automation during funnel flow.

Updated on: 01/06/2026