How to evaluate webhook infrastructure
Evaluate webhook infrastructure on five answers: the delivery guarantee, the exact retry schedule and total retry window, how a single failing endpoint is contained, how signatures are generated and rotated, and what the delivery log lets you search and replay. A design or vendor that cannot state all five in numbers has not been tested at scale.
Those five apply equally to a managed service and to a system your own team is proposing to build. The rest of this guide is what each answer should sound like, and what a vague answer tells you.
Delivery guarantee, and what it costs the receiver
Almost every real system is at-least-once: a delivery that times out is retried, and the receiver may have already processed it. That is the correct tradeoff, but it moves work to your customers, who now need idempotent handlers. So the follow-up question matters more than the guarantee itself: does every delivery carry a stable message ID that stays the same across retries, so a receiver can deduplicate on it? Without that ID, "at-least-once" means your customers cannot tell a retry from a new event.
Ask about ordering separately. Most webhook systems do not promise it, and pretending otherwise is worse than saying so, because a receiver that assumes order will corrupt state the first time two events land out of sequence.
The retry schedule is a number, not a promise
"We retry failed deliveries" is not an answer. The answer is a list: how many attempts, at what intervals, over what total window, and where the delivery goes when the window closes. A typical published schedule is around eight attempts spread over roughly 24 hours with exponential backoff and jitter, ending in a dead-letter queue rather than a silent drop. Compare that against the recovery time of a customer who deploys a bad build on a Friday.
Then ask what you can do with a failed delivery afterwards: replay one event, replay everything that failed for one endpoint in a time range, or nothing. Replay is the difference between an incident that ends in a support ticket and one that ends in a data-repair script. Our page on webhook reliability covers the numbers to expect on each of these.
How one broken endpoint is contained
Delivery throughput is a function of receiver latency, not your hardware, so the containment controls decide whether one customer's outage becomes yours. Look for a short delivery timeout measured in seconds, a concurrency cap per endpoint so no single destination can occupy the worker pool, an automatic disable or circuit breaker after a sustained failure streak, and a per-endpoint rate limit that keeps a recovered receiver from getting an hour of backlog at once.
Capacity itself follows from fan-out: one event multiplied by the endpoints subscribed to it. Multiply your event rate by average subscribers per event type before comparing any throughput claim, and see webhook scalability for how that arithmetic breaks pools sized on event rate alone.
Signatures and secret rotation
Ask which signing scheme is used and whether it is documented publicly. The Standard Webhooks specification defines an HMAC-SHA256 over the message ID, timestamp, and body, delivered in webhook-signature alongside webhook-id and webhook-timestamp, with receivers rejecting timestamps outside a tolerance window of about five minutes. A webhook signature built that way can be verified with an off-the-shelf library in any language, which is a real cost saving for your customers.
The rotation question is the one teams forget. Secret rotation requires two secrets to be valid at once for an overlap window, otherwise every rotation is a scheduled outage for whoever has not updated their config yet.
What the delivery log has to answer
The delivery log is where your support cost lives. It should let you find every attempt for one endpoint, show the response code and body the receiver returned, keep that history long enough to answer a question about last week, and expose the same view to your customers so they can debug without opening a ticket. Retention length and whether full payloads are stored are the two variables that drive both the bill and the usefulness.
Build versus buy, priced over the second year
A first version of webhook infrastructure is a queue and a worker pool, and a competent team ships it in a few weeks. The cost is the second year: per-endpoint backoff, dead-letter handling, replay tooling, signature rotation, a customer-facing portal, and someone on call for all of it. Price the build against that list rather than against the prototype, and read building a webhook sender for what the full scope looks like.
Svix is that layer as a service: one API call fans out to every subscribed endpoint with the retry schedule, signatures, dead-letter handling, and searchable delivery log already in place. If webhooks are a feature of your product rather than the product, the evaluation usually comes down to how much of the second-year list you want to own.
Frequently asked questions
What should I ask a webhook provider before signing?
Ask for the published retry schedule and total retry window, the delivery timeout, the signing scheme and whether two secrets can be active during rotation, the delivery log retention period, and whether customers can replay failed deliveries themselves. Vague answers on any of the five usually mean the feature does not exist.
Does at-least-once delivery mean I will get duplicates?
Yes, eventually. A receiver that processes an event but responds too slowly will be retried, so the same event arrives twice. Deduplicate on the message ID that ships with each delivery and make handlers idempotent, which is the standard fix and costs far less than trying to eliminate duplicates at the sender.
Is a webhook gateway enough, or do I need full infrastructure?
A webhook gateway centralizes verification, routing, and retries in front of receivers you control, which is enough when you only consume webhooks. Sending webhooks to customers adds fan-out, per-endpoint isolation, secret rotation, and a customer-facing delivery log, and those are what the full platform exists for.
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