Webhook Delivery Guarantees: Comparing Hookdeck, Svix, Inngest, and AWS EventBridge

Every major managed webhook service offers at-least-once delivery, not exactly-once, when it comes to delivery guarantees. What separates them is how they handle the gap: retry policies, deduplication windows, failure recovery tools, and whether they expect you to wire up idempotency yourself. This guide compares Hookdeck Event Gateway, Svix, Inngest, and AWS EventBridge on every dimension that matters for production reliability.

Comparison matrix

	Hookdeck	Svix	Inngest	AWS EventBridge	DIY (queue-backed)
Stated guarantee	At-least-once	At-least-once	At-least-once (implicit)	At-least-once†	At-least-once
Default retries	Up to 50 (configurable)	8 attempts	5 attempts (4 retries)	Up to 185 over 24h	You define
Backoff	Linear or exponential	Exponential (immediate → 10h)	Exponential + jitter	Exponential + jitter	You define
Max retry window	Configurable	~42 hours	Configurable	24 hours	You define
Deduplication window	1 second–1 hour (configurable)	24-hour event ID uniqueness	24-hour (event + function-level)	None built-in	You build
Idempotency key support	Header added automatically	webhook-id header + API key	CEL expression-based	None	You build
Dead-letter queue	Issues (no traditional DLQ)	Yes (SQS-backed, redrive via API)	No (Replay feature)	Yes (SQS)	Yes (SQS / RabbitMQ)
Manual retry / replay UI	Yes (bulk replay, bookmarks)	Yes (UI + API)	Yes (Replay feature)	Manual DLQ redrive only	You build
Ordering guarantees	None	FIFO (Enterprise only)	Per-function sequential	None for HTTP delivery	SQS FIFO (yes)
Self-hostable / open-source	No	Yes (reduced feature parity)	Yes	No	Yes

† EventBridge silently drops events when retries are exhausted and no DLQ is configured.

For a broader comparison of managed webhook platforms — including pricing, source coverage, and observability depth — see Best Webhook Management Platforms.

What "at-least-once" actually means

No mainstream webhook service offers exactly-once delivery. Distributed systems make it mathematically impossible to guarantee both delivery and exactly-once semantics without sacrificing availability — this is the FLP impossibility theorem in practice.

At-least-once means: your endpoint will receive the event, but may receive it more than once. Network blips, server restarts, and concurrent retries all create duplicates. The correct response is building idempotent event handlers on the consuming side — code that produces the same result whether it runs once or ten times.

The practical difference between services isn't whether they deliver at-least-once. They all do. It's how well they equip you to handle the gap via deduplication tools, idempotency headers, configurable retry windows, and failure recovery workflows.

For a deeper grounding in the theory, read At-Least-Once vs. Exactly-Once Webhook Delivery Guarantees.

How each service implements delivery reliability

Hookdeck Event Gateway

Hookdeck Event Gateway guarantees at-least-once delivery with configurable retry logic, infrastructure-level deduplication, and an observability layer that replaces the traditional dead-letter queue model.

Retry behavior: Up to 50 automatic retries per event with either linear or exponential backoff. Hookdeck's retry policy is fully configurable per connection: interval granularity down to 1 second, status-code-based rules (retry only on 5xx, exclude 429s), and respect for destination Retry-After headers — including -1 to cancel retries entirely. There's no opinionated default; you configure the policy when you set up a connection.

Idempotency model: Hookdeck adds idempotency headers to every forwarded event automatically, giving receiving applications the data they need to deduplicate. Configurable deduplication windows (1 second to 1 hour) drop identical payloads before they reach your endpoint. Field-based strategies let you ignore ephemeral fields (like timestamps) that would otherwise break dedup matching.

Failure handling: Instead of a dead-letter queue, Hookdeck uses Issues — auto-grouped failure clusters organized by connection and status code. Issues integrate with Slack, PagerDuty, BetterStack and Discord for alerting, support team assignment, and enable one-click bulk retry with built-in rate limiting. Failed events remain searchable in the same interface as successful ones. The dashboard also supports bookmarks for replaying specific test events — particularly useful when debugging retry behavior locally via the CLI.

Where it falls short: No ordering guarantees. Events are delivered best-effort, not sequentially. If strict FIFO is a hard requirement, you'll need application-level ordering logic. Hookdeck Event Gateway is also not self-hostable — if compliance or architecture requirements demand on-premise deployment, this is a constraint.

Hookdeck's role: Managed webhook gateway focused on inbound reliability with best-in-class observability. Purpose-built for the full development-to-production workflow: the CLI proxies live events to localhost for testing, Issues surfaces failures for recovery, and bulk replay closes the gap on anything that slipped through.

Svix

Svix guarantees at-least-once delivery with a fixed 8-attempt exponential backoff schedule and optional FIFO ordering on Enterprise plans.

Retry behavior: Svix's retry schedule is opinionated and fixed: immediate, 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, 10 hours — approximately 42 hours total. Only 2xx responses within 15 seconds indicate success; anything else is retried. If an endpoint fails consistently for 5 days, Svix automatically disables it and emits an EndpointDisabledEvent operational webhook.

Idempotency model: Every webhook carries a webhook-id header that stays constant across all retry attempts for the same message. Store that ID with a 24-hour TTL and ignore duplicates — straightforward receiver-side deduplication. Svix also offers a separate API idempotency key for safe POST request retries, cached for 12 hours.

Failure handling: When all 8 attempts are exhausted, Svix emits a message.attempt.exhausted operational webhook. You can monitor DLQ depth via the svix.queue.depth_dlq metric and redrive via API. The UI supports single-message resend and batch recovery across a chosen date/time window.

Where it falls short: FIFO delivery is Enterprise-only — not available at lower tiers, and it carries a throughput tradeoff (sequential processing caps at roughly 20 messages/second). The retry schedule isn't configurable per destination or by status code. Svix Dispatch is primarily a sender-side platform — designed for companies sending webhooks to their customers. If you need to receive and process third-party webhooks from Stripe, GitHub, or Shopify, Svix Ingest is a different (and less mature) product. Hookdeck is purpose-built for the inbound receiving use case with deeper observability across the full event lifecycle.

Inngest

Inngest is a workflow engine, not a webhook gateway. It provides durable step-function execution where each step is independently retriable and stateful. If your use case is orchestrating multi-step workflows triggered by events, rather than reliably delivering raw webhook payloads to HTTP endpoints, then Inngest is a strong choice.

Retry behavior: Default 4 retries (5 total attempts) with exponential backoff and jitter. Retries are configurable per function or per step, and RetryAfterError supports custom retry timing. Each step within a function maintains its own independent retry counter, so a failed payment notification step doesn't reset the retry count for an email confirmation step.

Idempotency model: Two-level idempotency: set a unique event ID at the event level (24-hour deduplication window), and optionally define CEL expression-based idempotency keys at the function level. More flexible than simple header-based dedup for complex workflow scenarios.

Failure handling: No DLQ. Inngest offers a Replay feature — selectively re-run functions against any events from history, filtered by date, status, or event type. The company positions this as replacing the DLQ pattern, with finer control over which events get re-processed.

Where it falls short: It's not a webhook proxy or gateway. There's no source normalization, no request inspection UI, no incoming event observability, and no equivalent to Hookdeck's CLI for local development. If you need to receive, filter, and forward raw webhook payloads, Inngest isn't the right tool — it's designed for the processing layer after an event has arrived. Hookdeck and Inngest are complementary rather than competing: Hookdeck receives and queues, Inngest processes.

AWS EventBridge

AWS EventBridge guarantees at-least-once delivery for HTTP endpoint targets via API Destinations — but only if you configure a dead-letter queue. Without a DLQ, events are silently dropped after retry exhaustion.

Retry behavior: Up to 185 attempts over a 24-hour window with exponential backoff and jitter. Retryable errors include 401, 409, 429, and 5xx responses. Respects the Retry-After header. The 5-second timeout for API destination requests is a hard limit — if your endpoint doesn't respond in time, EventBridge treats it as a failure and retries.

Idempotency model: None built-in. EventBridge passes no equivalent of a webhook-id header to your HTTP endpoint. Deduplication and idempotency must be implemented entirely in your receiving application, with no platform-level assistance.

Failure handling: SQS-based dead-letter queue, configurable per rule or per target. Captured events include metadata (rule ARN, error code, retry attempt count). Manual recovery requires re-processing the SQS DLQ yourself — there's no built-in replay UI. This is functional but demands significant operational work to build the equivalent of Hookdeck's Issues.

Where it falls short: EventBridge is a cloud event router, not a webhook management platform. There's no webhook-specific observability, no source normalization, no per-destination retry configuration, and no developer tooling for local testing. It also locks you into AWS infrastructure. If your team is already AWS-native and routing events between internal services, EventBridge is sensible. For receiving external webhooks at production scale with visibility into what's failing and why, it requires significantly more engineering to match what Hookdeck provides out of the box.

 

Decision framework: which service for which workload

Receiving webhooks from third-party services (the most common case)

Stripe, Shopify, GitHub, Twilio, Paddle — most webhook work is receiving events from someone else's platform. This needs source-specific signature verification, payload normalization, retry policies tuned to each source's quirks, and visibility into what's failing per-source.

EventBridge has no source normalization. Inngest isn't a gateway at all. Svix Ingest is a secondary product within Svix without the source coverage or observability depth of a purpose-built gateway. DIY means re-solving each source's signature verification, retry, and dedup behavior individually.

Recommendation: Hookdeck Event Gateway. 120+ pre-configured sources, per-source retry policies, and the Hookdeck CLI on every Stripe/Shopify/GitHub project from day one.

Strictly ordered events

Most systems that think they need FIFO actually need idempotent processing with sequence validation — checking version or updated_at on the receiving side and discarding stale updates. That pattern works with any at-least-once delivery service and scales horizontally.

Genuine FIFO is the only option for some workloads (e.g., append-only audit streams where ordering is the contract). For those, Svix Enterprise offers FIFO endpoints — but at a real cost: sequential delivery caps throughput at roughly 20 messages per second per endpoint. If your workload is genuinely high-volume and genuinely ordering-sensitive, you should look at log-based systems like Kafka or Kinesis instead.

Low-volume, internal services

For lightweight internal webhook ingestion (a few hundred events per day between internal services) Hookdeck's CLI is the lowest-friction entry point: hookdeck listen 3000 proxies live webhook events to localhost with no configuration, no AWS account setup, and immediate observability into what's failing. AWS EventBridge or DIY with SQS work if your team is already AWS-native and has engineering capacity for the operational scaffolding.

Recommendation: Hookdeck free tier for teams that want DX without configuration overhead. EventBridge or DIY if you're already invested in AWS infrastructure.

Hookdeck for reliable webhook delivery

Every service in this comparison delivers at-least-once. The difference is what they hand you for closing the gap — and how much of the work falls on your application code versus the platform. Hookdeck's combination of configurable retries, infrastructure-level deduplication, automatic idempotency headers, and Issues-based failure recovery moves the most webhook reliability work out of your application of any option here.

If your workload is sending webhooks to customers, Hookdeck Outpost covers the same ground for the producer side, with full open-source parity and per-event pricing roughly 10x lower than alternatives.