Workflow Triggers and Webhooks Explained
Start workflows from events, schedules or other systems, and secure the entry point.
Three kinds of triggers
Event triggers start a workflow when something happens inside the platform: a contract is added, a proposal is accepted, a document is signed. Schedule triggers run on a timetable, such as every Monday morning. External triggers start from another system through a webhook: the client's website form, CRM or app sends a request to the workflow's own address. Choose the trigger closest to the real start of the work.
Calling a workflow webhook
A webhook is an HTTP endpoint that accepts data and starts a run. The sending system posts a small JSON body with the fields the workflow needs. Keep the payload simple and validate it on arrival: required fields, email format and sensible lengths. The example below is illustrative; check your platform's documentation for the exact address and fields.
Protect the entry point
Treat a webhook address like a key. Keep it out of public client-side code where possible, send from a server, and rotate it if it leaks. Rate limit incoming requests and check required fields. For runs started by the public, any step that contacts a customer or spends money should ask a person first. These defaults stop spam and abuse from becoming real actions.
- Send from a server, not the browser, where possible
- Validate fields on arrival
- Rate limit and rotate leaked addresses
- Ask a person before customer-facing steps on public runs
Worked example: a form to a workflow
A consultancy's website form collected name, email, company and a message. The developer added a server function that posted these fields to the workflow's webhook address after basic validation, and returned a thank you page to the visitor. The workflow drafted a reply and a short proposal outline, then waited for a consultant's approval before anything was sent.
When a bot started submitting junk, rate limits and the approval step meant nothing reached real customers, and the address was rotated in minutes.
Common trigger mistakes
Triggers are the front door of a workflow. Weak doors let in noise, duplicates and abuse.
- Exposing the webhook address in browser code
- No validation of required fields
- Choosing a schedule when an event would be timelier
- Letting public runs contact customers without approval
- Use event, schedule or external triggers, whichever matches the real start.
- Keep webhook payloads small and validated.
- Treat webhook addresses like keys.
- Public runs should ask before customer-facing actions.
For one client process, choose the trigger and write the JSON payload it needs. List the validation rules you would apply and decide which steps must ask a person for runs started from a public form.
Check your understanding
1. Which trigger fits a website contact form?
2. Why validate webhook payloads?
3. What should public runs do before contacting customers?
Turn what you learn into monthly income
Resell AI agents and apps under your own brand. Up to 30% off credits, up to 30% recurring share, and apps built by XDQ Labs for your clients. Free to join.
From USD 49 or INR 2,999 a month. A person approves every step.
Templates from our playbooks
Copy ready templates with when to use each one and why it works.