Webhook

An HTTP callback sent from one app to another in real time when an event occurs, often used as the entry point to automations.

A webhook is an HTTP callback fired on events—like record changes or payments—to notify another system in real time. It carries the event payload to start downstream work.

Teams use webhooks for CRM updates, payment events, and support tickets to kick off automations without polling. They provide timely, push-based signals.

In workflows, webhooks map to triggers with validation, retries, and idempotency. Proper handling prevents missed or duplicated events and keeps runs reliable.

Frequently Asked Questions

How do I secure webhooks?

Validate signatures, use HTTPS, require secrets in headers, and restrict IPs if possible. Reject requests failing validation.

What if my endpoint is down?

Return non-2xx so the sender retries (if supported). Use queues/DLQs on your side and monitor uptime.

How do I avoid duplicate processing?

Use idempotency keys or event IDs. Store processed IDs and ignore repeats within a window.

What should I log?

Event ID, headers, timestamps, validation status, and response. Keep correlation IDs for tracing.

Can I transform payloads?

Yes—normalize to your schema before processing. Validate required fields and handle missing data gracefully.

How fast should I respond?

Quickly—ack and offload to async processing. Many providers enforce short timeouts; avoid long work in the handler.

Do webhooks replace polling?

Often, but keep a fallback sync or reconciliation for missed events. Combine with periodic checks for safety.

How do I test webhooks?

Use provider test events, tunneling tools, and staging endpoints. Verify signature handling and retries.

What about ordering?

Don’t assume global order. Use timestamps and IDs; enforce per-entity ordering in your handlers if needed.

Hourglass background
Ready to move faster

Ship glossary-backed automations

Plan Your First 90 Days