Webhooks and event-driven delivery
Compare polling with callbacks and learn what makes a webhook reliable enough for real workflows.
Why this matters
Constantly asking 'anything new?' wastes requests and introduces delay. A webhook lets one system call another when an event happens, but delivery still needs retry and duplicate-handling rules.
Learn it
A webhook is usually an HTTP request sent to a configured callback URL when an event occurs. The sender chooses when to deliver; the receiver authenticates or verifies the request, returns an appropriate status, and processes the payload. Reliable designs consider retries, idempotency, ordering, signatures or credentials, timeouts, and dead-letter/recovery behavior.
Work through an example
A field-data system can send a callback after a new submission instead of a destination polling every minute. The receiver may still receive the same event more than once if retries occur.
event occurs → POST callback → verify → deduplicate → process → acknowledgePractice
- 1Define one event that should trigger a webhook.
- 2Choose an event ID the receiver can use for idempotency.
- 3Describe what the sender should do if the receiver returns an error.
What to watch for
A webhook is not guaranteed exactly-once delivery unless the entire system explicitly provides that guarantee. Design receivers to handle duplicates safely.
Where this takes you
Webhooks fit connector events, notifications, workflow triggers, form submissions, and integrations where low-latency change delivery matters.