What is at-least-once delivery?
At-least-once delivery is the guarantee that every message reaches the receiver at least one time, accepting that some messages will arrive more than once. It is the delivery semantic virtually every serious webhook provider offers, because the alternatives are worse: at-most-once drops events when anything fails, and exactly-once is not achievable across two systems connected by HTTP.
Where the guarantee comes from
A webhook delivery is an HTTP POST that the provider considers successful when it receives a 2xx response. At-least-once falls out of two commitments layered on top of that.
First, the provider persists the message before attempting delivery, so a crash or deploy on the provider's side doesn't lose it. Second, the provider retries failed attempts on a schedule, usually with exponential backoff spread over hours or days, until a 2xx arrives or the schedule is exhausted. Messages that exhaust their retries land in a dead letter queue or a delivery log where they can be replayed manually, which keeps "we gave up" from silently becoming "it never happened."
Why duplicates are the price
The retry commitment is exactly what produces duplicates. When the provider times out waiting for a response, there are two possibilities it cannot distinguish: the request never reached the receiver, or the receiver processed it and the response got lost. Retrying is correct in the first case and produces a duplicate in the second. Any system that refuses to retry in that ambiguous situation is at-most-once; any system that retries is at-least-once. There is no third option over HTTP.
This is why the guarantee is honest rather than sloppy. A provider advertising at-least-once is telling receivers precisely what to build for: handlers that tolerate repeats. The receiving pattern, deduplicating on the message ID, is covered in the idempotency entry; providers following the Standard Webhooks specification make it possible by sending a stable webhook-id header with every message and every retry of it.
What at-least-once does not promise
Ordering. A message that fails and retries arrives after messages created later than it. At-least-once says every message lands, not that they land in sequence. Receivers that need order compare timestamps or version numbers from the payload rather than trusting arrival order.
Timeliness. A message delivered on the fifth retry may be hours old. The guarantee is about eventual arrival, which is one reason payloads should carry their own timestamps.
Delivery despite a dead endpoint. Retry schedules end. An endpoint that is down for three days will exhaust most schedules, at which point the message survives only in the provider's logs or DLQ. Providers typically disable endpoints that fail continuously and notify the owner, and receivers can replay the gap once the endpoint is healthy.
Comparing the three semantics
| Guarantee | Lost messages | Duplicates | Achievable over HTTP |
|---|---|---|---|
| At-most-once | Yes | No | Yes |
| At-least-once | No | Yes | Yes |
| Exactly-once | No | No | Not as a transport guarantee |
At-most-once is fire-and-forget: one attempt, no persistence, and any failure loses the event. It is acceptable only when individual events are disposable, like high-frequency metrics. Exactly-once is what everyone wants and no webhook transport can honestly promise; the practical version is at-least-once delivery combined with idempotent processing, which yields exactly-once effects.
The delivery guarantees lesson covers how providers implement the persistence and retry machinery behind the guarantee.
Frequently asked questions
Why do webhook providers use at-least-once delivery?
Because over HTTP the only alternatives are dropping events on any failure (at-most-once) or promising exactly-once, which cannot be honestly guaranteed across two independent systems. At-least-once keeps every event alive at the cost of occasional duplicates, which receivers can handle with idempotent processing.
How often do duplicate webhook deliveries actually happen?
Rarely as a fraction of traffic, since they require a response to be lost after processing succeeded. But at volume they are routine: deploys, proxy blips, and slow handlers all trigger retries, so any integration running long enough will see duplicates. Build for them from day one.
Does at-least-once delivery guarantee ordering?
No. A retried message arrives after messages that were created later, so arrival order is not creation order. Receivers that need ordering should compare timestamps or version numbers carried in the payload.
What happens when all retries fail?
The message leaves the retry loop and survives in the provider's delivery logs or dead letter queue, and good providers disable the failing endpoint and notify its owner. From there the messages can be replayed once the endpoint is healthy, so exhausted retries mean delayed, not lost.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis