Member-only story
Stop Lying to Your Webhooks
Simanta Sarma6 min read·1 day ago--
Why reliable webhook architectures treat events as signals, not sources of truth.
Part of the “Stop Lying to Your Stack” series
AI has made webhook integration look deceptively simple. Create a controller, accept a JSON body, parse a few fields, and call the service that updates your database.
That is not webhook processing. That is receiving a request.
The real work starts after the payload arrives. External systems retry, Queues redeliver, and Schedulers overlap, and as a result Payloads omit fields. A message that looks like a complete update is often only a signal that something changed somewhere else.
I have seen teams treat webhooks as synchronous API calls in disguise. That works in demos. It fails in production, especially when the webhook is coming from an external system that has its own retry rules, its own event IDs, and its own idea of what “updated” means.
This article is about the architecture line I now draw around webhooks: receive, store, claim, dispatch, and sync.
A Webhook Is Not the Source of Truth
The most common lie is assuming the webhook payload is the complete truth.
