About Webhook Node
The Webhook node sends profile data to an external system via an HTTP API call. It's how you connect your Marketing Automation flows to CRMs, e-commerce platforms, workflow tools, and any other system that accepts API requests.
This is a technical node — setting it up correctly typically requires knowledge of APIs, HTTP methods, and the receiving system's endpoint documentation.
In this article
When to use the Webhook node
Use the Webhook node whenever your flow needs to send data from Apsis One to an external system in real time, as profiles pass through the flow. Common reasons:
CRM sync — push lead or customer data to your CRM when a profile reaches a certain stage.
Workflow triggers — trigger an external workflow (e.g. in Zapier, n8n, Make) from a flow event.
E-commerce integration — sync purchase or engagement data to your e-commerce platform.
Custom applications — send data to any system with an API endpoint.
⚠️ Developer involvement recommended
Setting up the Webhook node requires understanding of APIs, HTTP methods, URL parameters, headers, and response codes. We recommend involving a developer or someone with technical API experience to ensure the configuration is correct and secure.
Common use cases
Push leads to a CRM
Profile completes a nurture flow and earns an MQL achievement → Webhook node (POST) sends profile name, email, company, and lead score to the CRM's lead creation endpoint. Sales sees the lead appear in their CRM immediately.
Trigger an external workflow
Profile submits a demo request form → flow triggers → Webhook node (POST) sends profile data to a Zapier/n8n/Make webhook URL → the workflow tool creates a task in the project management system, sends a Slack notification, and books a calendar slot.
Sync data to an e-commerce platform
Profile reaches a loyalty milestone in the flow → Webhook node (PUT) updates the customer's loyalty tier in the e-commerce system's customer API.
Send unsubscribe data to an external system
Profile unsubscribes (Listen node: Consent Timeline) → Webhook node (POST) sends the profile's email and unsubscribe timestamp to the external system to keep consent records in sync.
Custom analytics or data warehousing
Profile completes a flow → Webhook node (POST) sends profile data and flow completion metadata to a custom analytics endpoint or data warehouse for cross-platform reporting.
Prerequisites
Before setting up a Webhook node, make sure you have:
Prerequisite | Details |
API endpoint URL | The full URL of the external system's API endpoint that will receive the data. Get this from the receiving system's documentation. |
HTTP method
| Know which method the endpoint expects: GET, POST, PUT, PATCH, or DELETE. This should be specified in the API documentation. |
Authentication details | If the endpoint requires authentication (API key, bearer token, etc.), you'll need to add this as a header. Get the credentials from the receiving system. |
Expected data format | Know what data fields the endpoint expects and in what format. The Webhook node sends data as URL parameters (query strings). |
Expected response
| Know what the endpoint returns on success (e.g. status code 200, a specific string value) so you can configure response handling. |
What data can you send?
The Webhook node can send two types of data from the profile:
Data type | Details |
Profile attributes | Any attribute stored on the profile — both default attributes (email, first name, last name) and custom attributes (lead score, company, etc.). Available for all flows. |
Triggering event data | Data from the event that triggered the flow via the Listen node — for example, which link was clicked, which form was submitted, or any custom event data fields. Only available when the Listen node is configured with a real-time event trigger. |
⚠️ Important — Data limitations
Only the triggering event's data can be sent. Data from older events stored on the profile's history cannot be included — only the event that originally brought the profile into the flow.
The Webhook node is one-directional. It sends data out of Apsis One. It cannot write data back to the profile. If you need to update a profile based on an external response, the external system must call the Apsis One API separately.
Data is sent as URL parameters (GET parameters), not as a request body payload. Keep this in mind when configuring the receiving endpoint.
Setting up the Webhook node
Drag the Webhook node onto the canvas and click it to open the configuration panel. Remember that you can duplicate a node within the same flow.
Select the HTTP method. See HTTP methods explained below.
Enter the endpoint URL. This is the full URL where the webhook will send the request — for example:
https://api.yourcrm.com/v1/leads. The URL supports static parameters.
Add profile data as URL parameters. See Adding profile data below.
Optional: Add headers. See Adding headers below.
Configure response handling. See Response handling below.
Configure error handling. See Error handling below.
HTTP methods explained
The HTTP method tells the receiving system what kind of action to perform. Choose the method specified in the receiving system's API documentation.
Method | Typical use |
GET | Retrieve data from the endpoint. Rarely used for sending profile data — but useful if the receiving system uses GET requests with URL parameters to trigger actions. |
POST | Create a new record at the endpoint. Most commonly used — e.g. creating a new lead in a CRM, triggering a workflow, or sending data to an analytics endpoint. |
PUT | Update an existing record at the endpoint. Replaces the full record — use when you want to overwrite an existing entry. |
PATCH | Partially update an existing record. Only updates the fields you send — leaves other fields untouched. |
DELETE | Delete a record at the endpoint. Rarely used in MA flows — but could be used to remove a record from an external system when a profile meets certain conditions. |
💡 Good to know - The specific behaviour of each HTTP method depends on the receiving API. The descriptions above are general conventions — always check the receiving system's documentation for exact behaviour.
Adding profile data as URL parameters
Profile data is sent as URL parameters (also called query parameters). Each parameter has a name (the key your receiving system expects) and a value (selected from profile attributes or event data).
In the data section, click to add a new parameter.
Enter the parameter name — this is the key the receiving API expects. For example: email, first_name, last_name. Check the receiving system's documentation for the exact field names.
Select the data source from the dropdown:
Default attributes — built-in profile fields (email, first name, last name, etc.)
Custom attributes — any custom attribute you've created on your profiles
Event data — data from the triggering event (only available when the Listen node uses an event trigger)
Repeat to add more parameters. Add as many as the receiving system needs.
💡 Tip — Parameter naming - The parameter name (key) must match exactly what the receiving API expects. If the API expects emailAddress and you send email, it won't be mapped correctly. Always check the API documentation.
Adding headers
Headers are additional information sent with the request — most commonly used for authentication and content type.
To add a header:
Click to add a new header.
Enter the header name and value.
Common headers
Header name | Purpose and example value |
| Authentication token or API key. Example: |
| Tells the receiving system the format of the data. Example: |
| Any custom header the receiving system requires. Check the API documentation. |
⚠️ Important — Keep credentials secure - API keys and tokens entered in header values are stored in the node configuration. Make sure only authorised team members have access to edit the flow. If an API key is compromised, regenerate it immediately in the receiving system.
Response handling
After the Webhook node sends the request, the receiving system sends back a response. You configure what the Webhook node should consider a successful response.
From the Response dropdown, choose the response type to evaluate:
Status code — check the HTTP status code returned (e.g. 200, 201, 204).
String value — check for a specific text string in the response body.
In Expected response, enter the value that indicates success. For example: status code
200, or string value"success".
If the actual response matches the expected response → the request is treated as successful. If it doesn't match → the error handling rules apply.
Error handling
Error handling determines what happens to the profile when the webhook request fails — either because the response doesn't match expectations, the URL is unreachable, or the server returns an error.
You can choose from three options:
Error action | What happens |
Next node — Yes | The profile continues down the Yes path, as if the request succeeded. Use this when the webhook is non-critical and you don't want errors to affect the profile's journey. |
Next node — No | The profile continues down the No path. Use this to create a separate error-handling path — for example, sending a notification to your team or retrying later. |
Exit flow | The profile is removed from the flow entirely. Use this only when the webhook is critical and the flow should not continue without a successful response. |
💡 Tip — Use the No path for error handling
In most cases, Next node — No is the safest option. It lets you build an error-handling branch: for example, the No path leads to an Update Profile node that tags the profile as "Webhook failed", followed by a Notification node that alerts your team. This way you know about failures without losing the profile from the flow.
Testing your webhook
Always test the Webhook node before activating the flow with live traffic. Here's how:
Step 1: Test with a webhook inspection tool
Before connecting to the real API, use a webhook inspection tool to verify the request is formatted correctly:
webhook.site — generates a unique URL that captures and displays incoming requests.
requestbin.com — similar tool for inspecting webhook payloads.
Set the Webhook node's URL to the test URL, activate the flow with a test profile (using the Listen node's segment filter), and check the inspection tool to see exactly what data was sent.
⚠️ Important — Use non-sensitive test data
When testing with external tools like webhook.site, use test profiles with non-sensitive data. These tools are publicly accessible — don't send real customer data through them.
Step 2: Test with the real endpoint
Once the request format looks correct, switch the URL to the real API endpoint. Run a test profile through and verify:
The request arrives at the endpoint.
The data is correctly mapped to the expected fields.
The response matches your expected response configuration.
The error handling works correctly (test by temporarily using a wrong URL to trigger an error).
Limitations
Keep these limitations in mind when planning your webhook integration:
Limitation | Details |
Data sent as URL parameters | Currently, the Webhook node sends data as GET-style URL parameters (query strings), not as a JSON request body. Some APIs may not support this format — check the receiving system's documentation. |
One-directional only | The node sends data out. It cannot receive data back and write it to the profile. If you need to update the profile based on the external response, the external system must call the Apsis One API. |
Only triggering event data | You can send data from the event that triggered the flow (via the Listen node). Data from older events stored on the profile cannot be sent. |
No retry mechanism | If the request fails, it is not automatically retried. The error handling action (Yes/No/Exit) is applied immediately. If you need retry logic, build it into the No path (e.g. Time node delay → another Webhook node) or handle it in the receiving system. |
No conditional data | You cannot include different data fields based on conditions. Every profile that reaches the Webhook node sends the same set of parameters (though values vary per profile). |
Troubleshooting
Issue | What to check |
Webhook not sending | Check Node Stats — are profiles reaching the node? If "passed through" is 0, the issue is upstream. Also verify the flow is Active. |
All profiles going down the error path | The request is failing for every profile. Common causes: incorrect URL, wrong HTTP method, authentication failure (check headers), or the receiving server is down. Test with webhook.site to see the raw request. |
Data not appearing in the receiving system | The request may be arriving but with wrong parameter names. Compare the parameter names in the Webhook node with what the receiving API expects. A mismatch in naming (e.g. |
Authentication errors (401/403) | Check the |
Event data not available | Event data is only available when the Listen node uses a real-time event trigger. If the Listen node uses a scheduled trigger (attributes, tags, segments), event data fields won't appear in the Webhook node's data selector. |
Receiving system gets empty values | The profile may not have data in the selected attribute. If the attribute is empty for a profile, the parameter is sent with an empty value. Check the profile in Audience to verify the data exists. |
Response code mismatch | You expected status code 200 but the API returns 201 (Created). Both are success codes, but the Webhook node only matches the exact value you specified. Update the expected response to match what the API actually returns. |
Tips & best practices
Always test with a webhook inspection tool first. Use webhook.site or requestbin.com to verify the exact request format before connecting to the real API. This catches parameter naming issues, missing headers, and formatting problems.
Use the No path for error handling. Set the error action to "Next node — No" and build an error-handling branch: tag the profile as "Webhook failed" and notify your team. Never use "Exit flow" unless the webhook is absolutely critical.
Keep authentication credentials up to date. API keys expire. Set a calendar reminder to check and rotate keys before they expire — a silently failing webhook can go unnoticed for weeks.
Document the integration. In the Goals section of the flow, note: the receiving system, the endpoint URL, what data is sent, and who to contact if the webhook fails. Future you (and your team) will thank you.
Monitor Node Stats. Check the Webhook node regularly on active flows. A sudden spike in errors (profiles going down the No/error path) indicates a problem with the receiving system.
Consider dedicated integration nodes first. If you're sending data to Efficy Enterprise or webCRM, use the dedicated Efficy Enterprise Node or webCRM Node — they're pre-configured and easier to set up than a generic Webhook.
Build retry logic in the No path if the integration is important. For example: No path → Time node (wait 1 hour) → second Webhook node (same configuration). This gives the receiving system time to recover from temporary outages.
Send only the data you need. Don't send every profile attribute just because you can. Send the minimum data the receiving system requires — this reduces complexity, improves performance, and minimises data privacy exposure.
Related articles
Marketing Automation Nodes — Overview of every node type.
Efficy Enterprise Node — Dedicated integration for Efficy Enterprise CRM.
webCRM Node — Dedicated integration for webCRM.
Send Unsubscribes to an External System Real-Time — A separate feature for real-time unsubscribe sync (not a node).
Update Profile Node — Tag profiles on the webhook error path.
Notification Node — Alert your team about webhook failures.
Use Custom Events — Sending events into Apsis One (the reverse direction of the Webhook node).
Navigate the Canvas — Flow settings and canvas features.
Key Terms Glossary — Definitions for all Marketing Automation terms.