Get Webhook URL
Add a Webhook trigger node to the canvas, open it and copy generated webhook URL.
Instant Webhook triggers for workflow automation
WEXTL® Webhook node [1] generates an unique inbound URL for any external system - to receive events inside workflows. Event can trigger automations with 1,300+ available integrations [2]. Condition or Filter nodes as checks [3] placed before important steps in workflows help systems run autonomously and safely. Respond to a Webhook node [1] gives the ability to send a specified response to external application that sent initial webhook event.
WEXTL® keeps every request on the visual workflow canvas [4] with its raw payload, headers, and downstream steps logged on the run history [3].
- GDPR
- Data Encryption
- 2FA
- Local Data Region
Webhook node settings in workflow builder on WEXTL®.
How to start with instant webhooks inside WEXTL® workflows?
Designed to give plug and play experience with inbound event handing - visible and traceable. Here is how customers typically [5] start with instant events in their WEXTL automations.
Use URL inside 3rd party
Save provided unique URL inside the application settings you want send events from.
Test the event
Run a test event to ensure the 3rd party system sends correct payload to WEXTL.
Build automation
Build the workflow using a Webhook node as a starting point of automation
How to build webhook based workflows on WEXTL®?
There are only 3 main steps to build a webhook based workflow [1] on WEXTL. Under 10 minutes [5] setup - from minting a unique URL and pasting it into your vendor to a live automation reacting to every inbound event and replying back to the sender.
STEP 1
Get an unique webhook URL
Add a Webhook trigger node [1] and copy the URL WEXTL generates. This URL is the starting point of every webhook based workflow - unique to this trigger, ready to receive events.
Webhook trigger
Paste this URL into your vendor's webhook settings. Every POST becomes a run on the canvas.
https://hook.wextl.com/w/8f2a91e4b7c3d1…
STEP 2
Verify incoming events
Paste the URL into the your application settings or any system that supports outbound events. Add a Condition node right after the trigger to check the sender signature or a shared secret [3] if needed - unverified requests exit on Ignore before any downstream step fires.
STEP 3
Build the automation, respond back
Add actions after the Condition node - all in one run with the same run id [5]. Use the Respond module [1] to reply back to the sender with a custom status code and body - useful for vendors that expect a specific ACK or retry on ambiguous responses.
How does WEXTL handle vendor webhook verification?
A webhook URL is public the moment you paste it into a vendor's dashboard - anyone who has it can POST to it. This may cause a behavior where unauthorized party sends requests to a webhook [5]. Add a Condition or JS Code [6] step right after the trigger [1] to check the signature header from sender (Stripe-Signature, GitHub's X-Hub-Signature-256) or a shared secret against a value in Credentials.
Most software retry a delivery if your endpoint does not answer fast enough [5]. WEXTL® acknowledges the POST and returns before the rest of the canvas [4] runs to prevent issues with 3rd party platforms. However, each webhook has its own rate-limit bucket at the same time - noisy sender cannot starve the others in your workspace.
If you don't plan to set complex webhook verifications - inside the workflow builder canvas you can set authorization secret for a webhook [3]. This is simple and common [5] way for gating webhooks from unathorized senders.
Video shows Webhook payload check setup with Condition node on WEXTL®.
How to send a response to a webhook from the workflow?
Add a Respond module [1] to send a custom HTTP reply back to the sender with customizable status code, headers, body.
Respond is a native node [3] inside Webhook app - it behaves identically to other nodes on the workflow canvas. It can be placedanywhere where a Webhook trigger node is used. Downstream nodes after Respond continue running since it acts just as regular node.
Wait for Webhook module [1] can pause the run until a matching callback arrives - useful for OAuth completion flows or async APIs where the vendor calls you back with a result. Both Respond and Wait for Webhook belong to the same Webhook app on WEXTL® [1].
Example of Webhook app used in workflow automation on WEXTL®.
1300+ apps you can trigger using a webhook
Some apps in WEXTL® Apps Library [2] have own instant triggers. For others, a Webhook node can act as inbound webhook event handler - so you are not limited by specific applications and still can trigger workflows instantly from 3rd party systems or from WEXTL itself.
Supported integrations
Frequently asked questions
A Webhook trigger fires the moment a source system POSTs an event — event-driven, no polling delay. A Scheduled trigger fires on a fixed interval regardless of whether new data exists. Use webhooks when the source supports outbound events; use scheduling when it only exposes a read-only API you have to poll.
An app trigger (Stripe, Gmail, Airtable) is a first-party connector WEXTL builds, hosts the auth flow for, and maintains — you pick an event type from a curated list. A Webhook trigger is generic: it mints a URL you paste into any vendor's webhook settings, without WEXTL building a connector for that vendor. Reach for an app trigger when one exists; reach for a Webhook trigger when the source is niche, internal, or not in the catalog yet.
The whole request lands on the canvas — body, query parameters, and headers all show on the trigger's run entry. Reference any field via the same mapping tokens the rest of the builder uses on any downstream node's parameters, so a Pipedrive, Slack, or JS Code step can read straight from what the vendor POSTed.
Open run history for that workflow. Each run keeps the raw payload the Webhook trigger received alongside the input and output of every downstream step, including the Condition or JS Code node that decided its path — no separate log store to reconcile.
Drop a JS Code node right after the Webhook trigger (and after any verification step) to normalize a vendor's field names or types before the payload reaches Pipedrive, Sheets, or any other app node — see the Custom Functions page for what the JS Code node itself can do.
Wire your next inbound event or explore more
References
List of resources used for writing this documentation page on WEXTL®. Follow a citation to jump straight to the source.
- WEXTL® Webhook node — inbound webhook trigger + Respond and Wait-for-Webhook modules.
- WEXTL® Apps Library — full catalog of supported app integrations.
- WEXTL® built-in workflow nodes — catalog of built-in nodes with per-node documentation pages.
- WEXTL® visual workflow builder — canvas for building and visually tracing automations.
- WEXTL® anonymized usage experience from customers — collected by support team and/or partners.
- WEXTL® JS Code node — custom JavaScript step node documentation.