Engineering
Webhook
Polling asks 'has anything changed?' on a timer. Webhooks invert it: the source calls you. That is cheaper, faster and the right default for event-driven integration.
The complications are all about delivery guarantees. Webhooks can arrive twice, arrive out of order, or not arrive at all when your endpoint was briefly down. A handler that assumes exactly-once, in-order delivery will corrupt data eventually.
The standard defenses: make handlers idempotent so a repeat is harmless, verify the signature so anyone cannot post to your endpoint, respond fast and process asynchronously, and keep a reconciliation job that catches whatever was missed.
Webhook handling is where integrations silently lose records, and the loss is usually discovered by a customer.
Commonly misunderstood
What people get wrong
The claim
“We receive the webhook, so the data is in sync.”
What is actually true
Until the one delivery that failed while you were deploying. A periodic reconciliation against the source is what makes sync a fact rather than an assumption.
Where this comes up
Services where it matters
Related terms
Next step
Working through a webhook decision?
Tell us the situation. We will give you the tradeoffs as we see them, including when the answer is that you do not need what you are being sold.
No pitch deck. A 30-minute conversation about what you are trying to achieve.