Flow trigger: Webhook

When does a Webhook flow fire?

As soon as an external system sends an HTTP request with event data to Keaz. That request carries a structured payload — for example a user id, an event type, and whatever details belong to the event. Keaz reads the payload and starts the flow you defined for that event.

The sequence:

1. The external system detects the event.
2. It sends the webhook to Keaz.
3. Keaz receives the data.
4. The matching flow starts.

The trigger is entirely event-based, so it does not depend on the contact being active. The event arrives, the flow runs.

How do I set up the trigger?

1. Create a flow under Flows.
2. Click the Starting point block.
3. On the right, select the trigger event Webhook.
4. Configure the external system integration.
5. Save.

Step 4 is the part that differs per system, because every tool describes its outgoing webhooks differently. If you are connecting something unusual, our support team can go through it with you.

Which systems and events can I connect?

Any system that can send an HTTP request — a shop, a CRM, a payment provider, your own backend. Because you define the event, the trigger is not limited to a fixed list. Events merchants send us:

• a purchase event, or a shipping status update
• a payment confirmed, or a payment that failed
• an account created in your own system
• an appointment booked in your scheduling tool
• a status change, or an update in your CRM

This is also how an offline event reaches WhatsApp. Something that happens at the counter, in a warehouse or in a back-office tool becomes a message, as long as the system holding it can send a webhook.

For orders in a connected shop you do not need a webhook — use the Contact Purchase trigger instead. And for reactivation based on data Keaz already holds, there is Smart Activation. Webhook is for the events those two do not cover.

What can I do with the data the webhook sends?

The payload is not only a signal to start, it is content. Because the request carries your own fields, the message can name the thing that actually happened — the order that shipped, the appointment that was booked, the invoice that failed — rather than a generic notification. That is what makes a webhook flow feel like part of your product instead of a mailing.

Why automate this instead of doing it by hand?

• The message goes out when the event happens, not when someone notices it
• Manual steps disappear from the process instead of being reassigned
• Any business logic can drive it, so the same mechanism scales from one use case to twenty
• Triggers stay under precise control even though they originate outside Keaz
• Online and offline events end up in the same channel

What has to be in place first?

1. A system that can send an HTTP request when the event occurs, and that knows which contact the event belongs to.
2. The contact exists in Keaz and can be matched to the payload.
3. The contact has a valid opt-in. A webhook proves that an event happened, not that you may message someone about it — opt-in levels covers what each level allows, and collecting WhatsApp opt-ins the GDPR-compliant way explains how to obtain that consent.