Losing a webhook means that the sender emitted an event, but your system never received it or failed to process it. Sometimes that goes unnoticed. Sometimes it turns into a problem involving money, customers, and your company’s reputation.
If you are building a chatbot, a lost webhook may mean a missed message from a user. The user does not receive an answer to their question. That is inconvenient, but not always critical: they may send the message again, or a support agent may eventually notice the issue.
If you are building a business integration with an external service, a lost webhook means a missed event that can disrupt a business process. An order may never reach the CRM, a delivery status may not update, an invoice may not be created, or a team may miss an important notification.
With banking or payment integrations, the situation becomes much more serious. A missed payment-confirmation webhook can leave a customer in the worst possible state: they have paid, but they have not received the product, service, or access they expected. Even when the issue can be fixed manually, it creates additional support work and damages trust.
Once your system serves real customers in production, losing an event is always a problem. In the worst cases, it can lead to financial losses, operational failures, and reputational damage.
Why Webhooks Get Lost
Webhooks can fail to arrive for many reasons: a temporary outage, an application error, an expired TLS certificate, an overloaded database, a misconfigured reverse proxy, or an issue at the infrastructure provider.
A separate class of risks appears during infrastructure changes.
Imagine that your business is growing and your current server can no longer handle the load. You deploy a new server and update the DNS record so that your domain points to its new IP address.
At first glance, this seems straightforward. But DNS changes do not propagate across the internet instantly. Different resolvers, ISPs, and corporate networks may cache the old address for the duration of the TTL, and sometimes longer because of their own infrastructure behaviour.
As a result, some senders may already be reaching the new server while others continue sending webhooks to the old one. For a period of time, events can arrive at both servers in an unpredictable order.
If the old server has already been shut down or is no longer processing requests, some webhooks may be lost. But even if both servers remain online, another problem appears: the same event may be processed twice.
For a chatbot, that might result in two identical replies to one message. For a business integration, it could mean duplicate orders, repeated notifications, or the same data being synchronised more than once.
In payment-related workflows, the consequences can be especially serious. Processing the same event twice without proper duplicate protection may lead to a product being issued twice, a balance being credited twice, or a payment being charged more than once.
Loss and Duplication Are Two Sides of the Same Problem
Reliable webhook handling must account for two scenarios at the same time:
An event does not reach the recipient on the first attempt.
The same event is delivered more than once.
That is why it is not enough to simply accept an HTTP request and return 200 OK. You need to think about what happens during temporary outages, application restarts, infrastructure migrations, and retries from the sending provider.
In practice, this usually means:
the sender should retry delivery after temporary failures;
the recipient should acknowledge the event quickly and process heavier work separately;
event handling should be idempotent, so receiving the same event again does not repeat the business operation;
event identifiers should be stored and used to detect duplicates;
during an infrastructure migration, the old endpoint should remain available long enough for the transition to complete;
delivery logs should make it possible to see which events were received, failed, retried, or processed more than once.
Reliability Should Be Part of the Architecture
Webhooks are often treated as a minor technical detail: one service sends a request, another accepts it, and the job is done.
In reality, webhooks are often part of a critical business process.
They can carry payments, orders, customer messages, subscription changes, CRM updates, and internal automation events. That is why delivery reliability, retries, event history, and duplicate protection should be designed into the system from the beginning, rather than added after the first incident.
Choosing a reliable webhook operator matters. It should do more than accept an incoming request. It should help you avoid losing events when a destination is temporarily unavailable, preserve delivery history, and give you a safe way to resend events when needed.
That is what Adal is built for: making webhook delivery predictable and observable, even when your infrastructure changes, a service briefly goes offline, or a local process is not running.
When events matter to your product and your business, the infrastructure that delivers them should be reliable too.