v2026.4.10
Release date: April 29, 2026
✨ New Features
Webhook Trigger Node in the Flow Builder
A new node type for receiving external webhooks and automatically starting flows from events sent by third-party systems such as sales platforms, ERPs, CRMs or any service that sends data via HTTP.
What is it for?
- Receive orders, events or notifications from external systems and start flows automatically
- Map fields from the webhook payload directly to flow variables
- Link or create customers and chats from the received data
- Route flow execution based on the event type (
body.event,body.type, etc.)
How to use?
- Drag the Webhook Trigger node into the flow builder
- Configure the authentication type (Bearer, custom header, query param, HMAC or Public)
- Copy the generated webhook URL and set it up in the external system
- Map body fields to flow variables
- (Optional) Configure the customer and chat binding
- (Optional) Configure event routing to direct the flow based on the type of event received
Configurable Webhook Authentication
The Webhook Trigger node supports five authentication modes:
| Type | Description |
|---|---|
| Bearer | Token in the Authorization: Bearer <token> header |
| Custom header | Token in any user-defined header |
| Query param | Token as a URL parameter (?token=xxx) |
| HMAC | Cryptographic signature verification (SHA-1, SHA-256, SHA-512) — compatible with services like Kiwify |
| Public | No authentication |
The token is auto-generated (or can be set manually) and stored encrypted in the database. Administrators can reveal the original token when needed.
IP and Origin Security
In the node's Security tab you can restrict webhook calls to:
- Specific IPs — list of allowed IPv4/IPv6 addresses
- Domains/Origins — list of allowed HTTP origins
Leave blank to accept any origin.
"Listen" Mode for Real-Time Testing
When opening the node in edit mode, the Listen button waits for a real webhook to arrive and shows:
- The full received payload (body, headers, query params)
- The caller's IP and origin (suggestion for the allowlist)
- Button to map variables directly from the received payload
- Button to copy the path of each field (e.g.
body.data[0].name)
The Logs panel also lets you expand previous requests and map variables from them.
Customer and Chat Binding
In the Customer & Chat tab you can configure automatic creation/update of customers and chats from received data:
Customer Binding (Multi-key lookup)
- Add customer fields by mapping the body path (e.g.
body.user.email → Email) - Enable the search icon 🔍 on fields used to find the customer (OR logic across marked fields)
- If the customer is not found, it is created automatically
- Smart update rules:
- Name: always updated
- Email / Phone: filled in the direct column if empty; otherwise added to
customer_contacts - Document: updated only if currently empty
- WhatsApp, Instagram, Telegram: added to
customer_contactswithout overwriting existing values
Chat Binding
- Select the channel (WhatsApp, email, Instagram, etc.)
- Provide the contact path in the body (e.g.
body.user.phone) - The chat is created or found automatically and linked to the customer
- The contact from the chat is added to
customer_contactsif it doesn't exist yet
Event-Based Routing
In the Events tab, configure conditional routing based on a payload field:
- Set the event path (e.g.
body.event,body.type) - Add cases with value and label — values support
interpolation - Each case generates an independent output edge on the node
- An else/fallback edge is always included for unmapped events
In the flow builder, the node's outputs are displayed as colored handles — orange for each case, gray for else.
🎯 Benefits
- ✅ Native integration with external systems without additional code
- ✅ HMAC support for platforms that use cryptographic signatures (Kiwify, etc.)
- ✅ Multi-field customer lookup (OR) — prevents duplicates
- ✅ Automatic customer and chat creation from webhook data
- ✅ Flow routing by received event type
- ✅ "Listen" mode for mapping variables without manually editing paths
- ✅ Encrypted token at rest — security by default