Hookdeck Event Gateway vs Inngest: Webhook Gateway and Durable Runtime Compared

When teams start building event-driven systems, especially ones that involve LLMs, agents, or multi-step background processing, Hookdeck Event Gateway and Inngest often come up in the same conversation. Both deal with events. Both promise reliability. Both have retries and replay. So which one do you pick?

Well, they're not really competing for the same job. Hookdeck Event Gateway is a webhook gateway: it sits at the ingress edge, receives webhooks from third-party providers, verifies signatures, queues, filters, routes, and reliably delivers them to your services. Inngest is a durable workflow runtime: it executes your code in checkpointed steps with per-step retries, so a function that crashes halfway through a seven-step process can resume at step five.

Most production systems that handle webhooks at scale end up wanting some of what each tool does. This comparison breaks down what each platform actually provides, where they overlap, where they don't, and when it makes sense to use one, the other, or both.

At a glance

The Event Gateway approach

Hookdeck Event Gateway is purpose-built for the inbound webhook problem: making sure that when an external provider fires an event, you receive it, you can prove you received it, and your downstream systems eventually process it — without writing and maintaining the boilerplate yourself. The product covers:

• Receiving webhooks from any source, with 120+ pre-configured integrations that handle signature verification for providers like Stripe, Shopify, GitHub, Twilio, and Paddle out of the box.
• Delivering webhooks to any destination reachable over HTTP — your application servers, a queue, a Lambda, an Inngest intake endpoint, or anywhere else.
• Filtering events at the gateway so you only forward the subset of webhooks your services care about.
• Transforming payloads to match the shape downstream systems expect.
• Durable queueing with backpressure absorption so a webhook storm doesn't take down your application.
• Retries and replay with linear or exponential backoff, plus bulk retry from the dashboard.
• Observability: a visual trace per request, full-text search across payloads, headers, and paths, and team workflows for tracking issues.
• Developer tools: a CLI that proxies live webhooks to localhost without breaking on restarts, and the Hookdeck Console for inspecting requests without an account.

The Event Gateway's job ends the moment your code receives the event. What happens next (running the function, calling an LLM, writing to a database) is your application's problem.

The Inngest approach

Inngest is a durable workflow runtime. You write functions using its SDK, define them as a series of steps, and Inngest persists state between steps so the function can survive crashes, deploys, and timeouts. The platform covers:

• Durable step functions — each step.run() is checkpointed, so a retry after a failure resumes at the failed step rather than re-running the whole function.
• Per-step retries with exponential backoff and jitter (4 retries by default, configurable per function or per step).
• Waitpoints — step.waitForEvent() and step.sleep() let a function pause for minutes, hours, or days while waiting for a downstream event or a human approval.
• Concurrency, throttling, and rate-limiting primitives configured at the function level.
• Deduplication at two layers: a 24-hour event-ID window, and function-level CEL expression idempotency keys.
• Replay — selectively re-run functions against any events in history, filtered by date, status, or event type.
• A function run dashboard that shows step-by-step execution traces, inputs and outputs, and the timing of every retry.
• A local dev server (npx inngest-cli dev) that emulates the production runtime so you can test functions before deploying.

Inngest's job begins after an event arrives in its system. How the event got there, whether a webhook provider fired it directly at Inngest's generic HTTP endpoint, or whether your own code emitted it, or whether a gateway delivered it, is an upstream concern.

For a broader take on where webhook gateways and durable runtimes fit relative to each other, see Webhook Gateways and Durable Runtimes: Two Tools for Reliable Agent Workflows.

Pre-configured webhook sources

The first practical difference shows up at the edge.

Hookdeck Event Gateway ships with 120+ pre-configured webhook sources. Each one knows how that provider signs its requests, what content types to expect, what the retry headers mean, and where the timestamp lives. Pointing Stripe, Shopify, or GitHub at Hookdeck is configuration, not code.

Inngest exposes a generic HTTP endpoint that accepts JSON events authenticated with its own API key. To accept a signed webhook from a third-party provider, you implement the integration yourself: verify the signature, normalize the payload, then call inngest.send(). Inngest does have a webhook transform feature for some providers, but it's a per-source script you write and maintain rather than a curated catalog of pre-configured integrations.

If you're receiving webhooks from external providers, a gateway absorbs the per-provider quirks. If you're emitting events from your own code, Inngest's SDK is the natural integration point.

Signature verification and edge security

Hookdeck Event Gateway verifies signatures at the gateway, before any forwarding happens. The configuration is per-source: paste in the Stripe secret, the Shopify shared secret, the GitHub webhook token, and the gateway rejects unsigned or tampered requests at the edge.

Inngest does not verify third-party webhook signatures by default — its security model is built around its own API-key authentication for inbound events. To accept signed webhooks securely, you implement the verification in your handler before calling inngest.send().

Centralizing signature verification at the gateway means every downstream consumer (Inngest, your app, a queue, an analytics pipeline) gets pre-verified events without having to know how each provider signs them.

Queueing and backpressure

Hookdeck Event Gateway absorbs the request from the provider into a durable queue and acknowledges it immediately. Downstream systems consume events from the queue at their own pace. If a downstream is slow or briefly unavailable, Hookdeck Event Gateway holds the events and retries delivery without the provider ever knowing there was a problem.

Inngest queues events for function execution once they've arrived in its system. The runtime will reliably persist events and retry function execution. But the moment between a third-party provider firing a webhook and the event landing in Inngest is your responsibility — you have to keep an endpoint up and answering quickly enough that the provider doesn't time out and retry.

For high-volume, bursty traffic (a Shopify flash sale, a Stripe end-of-month dispatch), a gateway in front absorbs the burst before any function code runs. For a deeper look at how delivery guarantees compare across managed services (including Inngest), see Webhook Delivery Guarantees: Comparing Hookdeck, Svix, Inngest, and AWS EventBridge.

Filtering and routing

Hookdeck Event Gateway lets you write filter rules against any field in the headers, path, query, or body. Events that don't match can be dropped, routed to a different destination, or flagged. Routing decisions happen at the gateway, before any downstream compute is spent.

Inngest routes events to functions by event name, with optional CEL expression matchers at the function level. The routing is logical rather than infrastructural — every function that matches a name will run, and you pay for the execution time of functions that ultimately discard the event in their first line of code.

If 80% of a provider's webhooks aren't relevant to your application, filtering at the gateway saves you from paying execution time on the 80% you'd discard anyway.

Deduplication

Hookdeck Event Gateway supports exact and field-based deduplication on a configurable window, applied at ingress. Duplicates are dropped before they ever reach downstream systems.

Inngest offers two layers of deduplication: a 24-hour event-level unique ID, and function-level CEL expression idempotency keys. Dedup is enforced when an event is sent to Inngest or when a function is triggered, so it protects against duplicate executions of your code.

The two are complementary. Edge dedup at the gateway keeps duplicates out of your processing pipeline entirely; function-level dedup ensures that even if a duplicate sneaks through, the same step doesn't run twice.

Transformations

Hookdeck Event Gateway provides a code editor and a visual transformation builder for reshaping payloads at ingress. Common uses include renaming fields to match Inngest's event.data schema, splitting one webhook into multiple events, or stripping personal data before forwarding downstream.

Inngest expects events in its own { name, data } shape. You can transform inside function code, or transform before calling inngest.send(). There's no first-class transformation layer between "webhook arrived" and "function runs."

If you want every downstream consumer to receive a normalised event shape (Inngest, your app, your data warehouse) a gateway transformation does it once at the edge rather than in every consumer.

Durable execution

This is where Inngest's category genuinely shines.

Hookdeck Event Gateway delivers the event to your code and is done. If your handler runs for 45 seconds and crashes at second 40, Hookdeck will retry the delivery, and your handler will run again from the start. The gateway has no model of what your code was in the middle of doing.

Inngest persists state between steps. If a function makes three LLM calls and a database write, and crashes between calls two and three, Inngest resumes at call three on retry — the expensive calls that already succeeded are not re-run. That's checkpointed execution, and it's not something a gateway provides.

The trade-off is that durable execution is overkill for handlers that finish in seconds and don't have meaningful step boundaries. If your code is "receive webhook, call one model, write one row, return," there are no checkpoints worth persisting. For when that distinction matters, see Why Most Webhook-Triggered Agents Don't Need a Workflow Engine.

Retries

Hookdeck Event Gateway retries delivery with linear or exponential backoff, configurable per connection. If your endpoint returns 500, Hookdeck Event Gateway retries the request until it succeeds, the retry policy is exhausted, or you intervene from the dashboard. The original request stays in storage for replay either way.

Inngest retries function execution — and crucially, retries individual steps. A retry after a partial failure re-runs only the failed step, not the whole function. The default is 4 retries with exponential backoff and jitter; both are configurable per function or per step.

These are different retry models. A gateway retries until your code returns 2xx. A runtime retries until each step inside your code returns success. When both are in front of the same handler, the gateway's retry of delivery and the runtime's retry of steps cooperate rather than overlap.

Replay

Hookdeck Event Gateway stores every webhook with the full request (headers, body, signature, response) and lets you replay any of them (singly or in bulk) from the dashboard, with full-text search and filters across history. The replay answers "the provider sent us an event — did our pipeline handle it correctly?"

Inngest has a Replay feature that re-runs functions against any events from history, filtered by date, status, or event type. It's designed for re-processing after a bug fix or for backfilling. The replay answers "a function had a bug — let's re-run it against the events it should have processed."

The two replay models address different questions and don't substitute for each other.

Observability

Hookdeck Event Gateway gives you a per-request visual trace: what the provider sent, whether the signature verified, what filters and transforms applied, what was delivered, and what the response was. Full-text search runs across payloads, headers, paths, and queries. Issues are first-class, with custom triggers, status, and team workflows.

Inngest gives you a per-function-run trace: the input event, each step's input and output, the timing of every step, retries that happened, and the eventual outcome. The dashboard is excellent for debugging what your code did.

These are different views on different layers. A gateway's dashboard tells you about webhooks; a runtime's dashboard tells you about executions. Teams running production webhook integrations usually want both.

Developer tools

Hookdeck Event Gateway ships the Hookdeck CLI for proxying live webhooks to localhost. Unlike ngrok, it supports multiple developers simultaneously, preserves history across restarts, and has bookmarks for replayable test events. The Hookdeck Console is a free, no-signup tool for inspecting webhooks and trying out 60+ provider samples.

Inngest ships a local development server that emulates the production runtime, lets you trigger events manually, and shows step-by-step execution against your local code. It's purpose-built for developing functions, not for forwarding webhooks from external providers.

Both are good at what they're for. For the local development of webhook handlers, the Hookdeck CLI is the lower-friction tool. For local development of durable functions, Inngest's dev server is. They coexist nicely.

Self-hostability

Hookdeck Event Gateway is a managed cloud service. There is no self-hosted version.

Inngest offers an open-source self-hosted runtime alongside its managed cloud. Self-hosted Inngest is real and supported, though the cloud version remains the most feature-rich.

Teams with strict data residency or air-gapped requirements may prefer Inngest's self-hosting; teams that don't want to operate infrastructure will prefer Hookdeck Event Gateway's managed model.

Pricing model

Hookdeck Event Gateway prices on events. There's a free tier; the paid Team plan starts at $39/mo. Throughput-based, so cost scales with the number of webhooks you process rather than how complex your processing is.

Inngest prices on function executions and step-seconds, with a free tier and paid plans that scale with workflow complexity.

For pure pass-through workloads (receive webhook, do one thing, return) gateway pricing is generally lower than execution-billed pricing at high volume, because you're not paying compute charges for trivial work. For complex multi-step workflows that genuinely use durable execution, paying per execution is reasonable.

Using Hookdeck Event Gateway and Inngest together

The most common production pattern is to put Hookdeck Event Gateway in front of Inngest:

1. Third-party providers (Stripe, Shopify, GitHub, Twilio, and so on) send signed webhooks to a Hookdeck Source URL.
2. Hookdeck Event Gateway verifies the signature, deduplicates, filters, and transforms the payload into the { name, data } shape Inngest expects.
3. Hookdeck Event Gateway delivers the event to an Inngest intake endpoint, attaching the appropriate authentication.
4. Inngest enqueues the event and runs whatever functions are subscribed to it, with checkpointed steps and per-step retries.

Each tool owns the layer it's good at. The gateway handles the edge (verification, dedup, observability of what the provider actually sent). The runtime handles the execution (durable state, step retries, waitpoints). Failure modes are scoped too: an Inngest outage doesn't lose webhooks because Hookdeck queues them and retries delivery; a downstream code bug doesn't lose webhooks because Hookdeck has the original request stored for replay.

This is the same pattern documented in GitHub Agent Automation: Hookdeck, Trigger.dev, and Claude — Trigger.dev is a different durable runtime, but the architecture is identical. Some teams keep most routing logic inside Inngest functions (one connection, one router task that fans out); others push routing to the gateway (a connection per event family with header filters). Both patterns work; where routing lives is a choice rather than a constraint.

When to choose Hookdeck Event Gateway alone

If your workload is "receive webhook from an external provider, do one or two simple things, return," Hookdeck Event Gateway alone is probably enough. A reliable gateway in front of a normal HTTP handler covers the failure modes that actually bite at this scale: timeouts, duplicates, transient downstream failures, provider retry storms. There's no need for checkpointed step state when your handler has no real steps to checkpoint.

Choose Hookdeck Event Gateway alone when you're integrating third-party webhooks into a conventional backend, when your processing is short-lived, when you care most about webhook-level observability and replay, and when the cognitive overhead of a workflow DSL outweighs its benefits for the work you're actually doing.

When to choose Inngest alone

If your events are being emitted by your own code rather than arriving as webhooks from external providers, you don't have a signed-webhook ingress problem to solve. Inngest's own inngest.send() is the natural integration point. You get durable execution, step retries, waitpoints, and scheduling out of the box without needing a gateway in front.

Choose Inngest alone when your workflows have five or more discrete steps, when they wait for external events or human approvals, when they need to survive deploys and container restarts mid-execution, when they have compensating transactions or sagas, or when they involve expensive per-step work (multi-dollar LLM calls, large data transforms) where re-running an entire function on a late failure is unaffordable.

When to use both

Use both when you're receiving webhooks from third-party providers and your downstream processing is a real workflow. The gateway pays for itself at the ingress edge (signature verification, dedup, replay, observability of what the provider actually sent); the runtime pays for itself at the execution layer (durable state, step retries, waitpoints).

The combination is also a low-risk starting point. Putting Hookdeck Event Gateway in front of a conventional handler is cheap. The day a workflow actually emerges (a multi-day onboarding flow, a human-approval step, etc. you put Inngest behind the gateway and migrate the affected handlers. The webhook producers don't notice; the ingress URLs don't change; the signature verification, dedup, and observability stay where they are.

Conclusion

Hookdeck Event Gateway and Inngest sit on either side of the line between receiving an event and processing an event. The gateway is purpose-built for the ingress layer: 120+ pre-configured providers, durable queueing with backpressure, filtering and transformations at the edge, full-text searchable observability, and replay over webhooks. Inngest is purpose-built for the execution layer: durable step state, per-step retries, waitpoints, scheduling, and replay over function runs.

For teams that receive third-party webhooks and run conventional handlers, Hookdeck Event Gateway alone covers the failure modes that matter. For teams whose workflows are genuinely long-running and multi-step, Inngest covers durable execution. For teams that have both (webhooks from outside, real workflows inside) Hookdeck and Inngest are complementary rather than competing, and putting one in front of the other gets each tool doing the part it's best at.