Once you’ve decided not to build webhook delivery yourself, the next question is which service to hand it to. There’s a short list of options, and from the outside they look alike: they all promise reliable delivery, retries, and signatures. The differences show up in production, usually at the worst possible moment. This is the checklist I’d work through, organized around the things that tend to go wrong.
Reliability and Delivery Guarantees
This is the reason the service exists, so it’s worth being picky.
Start with the delivery guarantee. Almost every service offers at-least-once delivery: every event lands at least one time, and occasionally more than once. That’s the honest standard. Be wary of anyone advertising exactly-once delivery, because it isn’t achievable without cooperation from the consumer, and a vendor that claims otherwise is either redefining the term or hoping you won’t ask.
Then the retry policy, which is where services differ the most. Ask how many attempts, over what window, and with what backoff. A service that gives up after three tries in an hour will drop events during any outage longer than an hour, and consumer outages routinely run longer than that. Look for retries spread across days, exponential backoff, and jitter so a recovering endpoint doesn’t get hit by a synchronized retry storm. Per-endpoint retry schedules are a nice bonus when different consumers have different tolerances.
Ask what happens to events that exhaust every retry. They need to go somewhere you can find them: a dead letter queue or a failed-event log you can inspect, with the ability to replay by hand and an alert when something lands there. A service that drops events silently after the last attempt is disqualifying, because you’ll only discover the loss when a customer does.
Finally, uptime. You want a published SLA (99.9% at minimum, 99.99% better), a status page with real incident history, and a clear answer on what the service does with events that fire while it’s down. A delivery service that drops your events during its own outage has inverted the whole point. The good ones queue and deliver on recovery.
Performance
Two numbers matter here: latency and throughput.
For latency, look past the average. p50 tells you the typical case; p99 tells you what a bad minute looks like. Ask specifically about first-attempt latency, the time from when you hand over an event to the first delivery attempt. A service that batches and flushes every thirty seconds behaves nothing like one that delivers in a second or two, even when their averages read the same.
For throughput, find the ceiling before you hit it. Sustained events per second, per-endpoint limits, whether there’s a burst allowance above the sustained rate, and how the service behaves during a spike. Size it against your peak, not your average, since the peak is usually the moment webhooks matter most.
Security
Signing comes first. The service should sign every delivery with HMAC using SHA-256 or better, with a unique secret per endpoint so a leaked secret is contained to one consumer. Check that you can rotate keys without downtime, and that signatures carry a timestamp so consumers can reject replayed requests. If you want the receiving side of this, our earlier post on HMAC signatures walks through verification.
Then the payload data. Encrypted at rest, TLS in transit, and a straight answer on where payloads are stored and for how long. If your events can carry sensitive data, that retention window and the storage encryption are what you’ll want to understand before you send the first one.
Network controls round it out. Stable, published source IPs let your consumers allowlist you. mTLS matters if any of your consumers require it. These are easy to skip past until a customer’s security review turns them into blockers.
Observability
Observability splits into two audiences, and a good service covers both.
For you, the sender, you should be able to see the delivery status of every event, search by ID, type, endpoint, time range, and status, and drill into each attempt for its response code, latency, and error. Aggregate metrics like success rate, latency percentiles, and retry rates, plus alerting on failures, turn “something feels off” into an actual answer. Our post on webhook observability goes deeper on what to instrument.
For your customers, the consumers, a self-service dashboard changes the economics of support. When they can see their own delivery history, inspect payloads and responses, send a test event, and replay their own failures, every question they answer themselves is a support ticket your team never opens. That capability is worth more than it looks on a feature list.
Developer Experience
You’ll live in this API, so try it before you commit. Sending a webhook should take a single call, not a sequence of create-subscription, create-endpoint, create-event. Look for SDKs in the languages you actually use, a sandbox for testing, and a way to fire a test event at a consumer endpoint to confirm it’s wired up correctly.
Documentation tells you how much the vendor respects your time. Quickstarts, language-specific examples, an API reference generated from an OpenAPI spec so it stays in sync with reality, documented error codes, and a changelog you can follow. Thin docs are a reliable predictor of thin support.
Operational Features
Beyond the basics, a few capabilities separate a service you can run a business on from one you’ll outgrow.
Endpoint management should be available both by API and through a portal your customers can use to register and manage their own endpoints, with health monitoring and the ability to pause and resume a single endpoint without touching the rest.
Event types and filtering let consumers subscribe to only what they care about, like order.created or payment.failed, rather than receiving everything and filtering on their end. Schema versioning helps when your events inevitably change shape.
Replay is the feature you’ll be grateful for during an incident. When a consumer’s endpoint was down for six hours and they’ve finally fixed it, you need to re-send that window, and those replays have to carry the same event IDs so consumers can deduplicate. Check that you can replay by time window, by endpoint, and by single event ID.
Rate limiting protects your consumers from you. The service should let you cap delivery per endpoint, honor 429 responses and Retry-After headers from consumers instead of hammering them, and let a consumer ask for a slower rate when it needs one.
Pricing
Webhook services price on some mix of events per month, number of endpoints, retention window, and which features are gated to which tier. The headline number is easy to compare; the traps are in the details.
Watch how retries are billed. If a single event that needs five retries counts as five events, one flaky consumer on a bad day can multiply your bill. Watch overage pricing, because a traffic spike is exactly when you don’t want a surprise invoice. Check whether the features you actually need, endpoint management, replay, a consumer dashboard, sit on your plan or are reserved for enterprise. And confirm the maximum payload size and what happens when an event exceeds it.
A Scorecard
If you’re comparing more than two services, score them against the same criteria instead of trusting your memory of three demo calls. Weight reliability and security heavily, since those are the parts you can’t easily bolt on later. Developer experience and pricing matter too, but you have more room to compromise there.
| Criteria | Weight | Service A | Service B | Service C |
|---|---|---|---|---|
| At-least-once guarantee | High | |||
| Retry policy (attempts, window, backoff) | High | |||
| Dead letter queue + manual replay | High | |||
| Uptime SLA + incident history | High | |||
| Delivery latency (p50, p99) | Medium | |||
| HMAC-SHA256 signing | High | |||
| Per-endpoint secrets + key rotation | Medium | |||
| Sender-side observability | High | |||
| Consumer-facing dashboard | Medium | |||
| Event replay (window / endpoint / ID) | High | |||
| SDKs in your languages | Medium | |||
| Integration effort | Medium | |||
| Per-endpoint rate limiting | Medium | |||
| Pricing clarity + retry billing | Medium |
Fill each cell with a rating and a note. The weights reflect what tends to hurt most in production: an event you can’t recover, or a signature a consumer can’t verify, is a worse Monday than an API that took an extra afternoon to integrate.
Where Hookbridge Fits
We built Hookbridge after spending too long on the wrong side of this checklist, so it scores the way we wished other services had:
- At-least-once delivery with configurable retries, exponential backoff with jitter, and a dead letter queue you can inspect and replay from
- Per-endpoint HMAC-SHA256 signing, key rotation without downtime, and timestamped signatures for replay protection
- Observability for both sides: delivery logs, metrics, and a consumer-facing dashboard so your customers can debug their own integrations
- Event replay by window, by endpoint, or by single ID, with stable event IDs for idempotent consumers
- A single API call to send, with SDKs in Go, Node, Python, PHP, and Ruby
- Pricing that doesn’t count retries against you
Run us through the framework above alongside whoever else is on your short list. If reliable delivery is something your product can’t be casual about, we think we’ll hold up well. Give Hookbridge a try.
That wraps our webhook fundamentals series. If you’re just arriving, What Are Webhooks? starts from the beginning, or you can jump straight to whichever problem is biting you right now.