Skip to content

All posts

Hookdeck alternatives: what to use instead, and when

6 min readThe Eventeer team

Hookdeck’s Event Gateway is built to sit in front of your application as webhook management and queueing infrastructure. Incoming requests are queued, can be filtered or reshaped with JavaScript, and are delivered to your endpoint with retries you can also trigger by hand. It also has a CLI that forwards events to localhost, and it is a strong product for that job.

People look for an alternative for reasons of fit, not quality. Some need events that are not webhooks at all, such as devices on a WebSocket. Some want to send webhooks to their own customers, which is a different problem. Others want to self-host or to build the pieces on a cloud they already run. Last reviewed: November 2026.

What to look for in a Hookdeck alternative

Start with the job, because these products are not interchangeable.

  • Which direction are the webhooks going? Receiving webhooks from providers, and sending webhooks to your own customers, need different tools.
  • Are all your events webhooks? If devices or feeds connect over WebSocket, a webhook gateway is only part of the answer.
  • Do you need to change payloads in flight? Transformations are a real dividing line.
  • Where must it run? Hosted service, or something you operate yourself.
  • What happens after delivery? Storage, replay, metrics and alerts on the events themselves.
  • How much do you want to build? A managed product, or queues and glue code you own.

The alternatives

Eventeer

Eventeer is a hosted event hub. Three kinds of input go in: webhooks to a listener URL, devices that keep a WebSocket open to Eventeer, and external WebSocket feeds that Eventeer connects to. Events are stored for 7, 30 or 90 days depending on the plan, and you can browse and replay them. Out come outbound webhooks to destinations, live streams that clients subscribe to over WebSocket, and messages pushed down to connected devices.

For the webhook job Hookdeck does, the overlap is real:

  • Listener URLs accept requests with anonymous, token or HMAC authentication, dedupe by Idempotency-Key, and take bodies up to 256 KB. The listener answers 202 and stores the raw event.
  • Destinations receive events signed with HMAC-SHA256, with at-least-once delivery and 8 retries over about 24 hours. Each destination can filter on one condition of the payload, and a failed delivery can be retried by hand from the delivery log.
  • Metrics on a JSON field, dashboards, and alerts (a threshold, or “no events for N minutes”) sit in the same product.

What Eventeer does not do:

  • No payload transformations. The filter is a single condition; you cannot rewrite a payload. Logic like that stays in your own service.
  • No CLI for local development. There is no tool that forwards events to localhost.
  • Hosted only. No self-hosted edition.
  • No customer-facing webhook sending. Destinations are configured by your team, not by your customers.

It fits when your inputs are mixed (webhooks plus devices or feeds), when you want to stream events to dashboards, or when you want metrics and alerts next to the stored events. See how to fan out one webhook to many consumers and how to replay failed webhooks for the details.

Svix

Svix’s documentation is centered on sending webhooks: you send a message and Svix delivers it to your customers’ endpoints, with automatic retries, a record of each attempt and a consumer application portal where customers manage their endpoints. That is the opposite direction from Hookdeck’s main use. Svix does have documentation for the receiving side, covering signature verification and testing tools, but the pages reviewed describe receiving as webhooks sent by Svix and its customers rather than a gateway for arbitrary providers.

Pick Svix if your product sends webhooks to customers. For receiving Stripe or GitHub events, it is not documented as a gateway.

Convoy

Convoy describes itself as a webhook gateway that manages both incoming and outgoing webhooks. Its site links to a GitHub repository and a “Self-Hosted Premium” option, and mentions request signing, rolling secrets and a playground for testing webhooks. The pages reviewed do not describe rate limits, replay or transformations, so check its docs for those before deciding.

Pick Convoy if you want one gateway for both directions and want to run it yourself.

A DIY setup on a cloud queue

You can build the core of a gateway from cloud parts. Amazon API Gateway can expose AWS services such as SNS, S3 and Kinesis through its AWS integration, and Amazon SQS supports dead-letter queues, where messages that fail processing are set aside and can be moved back with a redrive. API Gateway does not retry when the endpoint times out, so the caller handles that. Everything else is yours to write: signature checks, deduplication, a log you can search, replay, alerts.

Pick this if you already run on that cloud, have the people to maintain it, and want full control. Expect to build the inspection and replay tooling that products like Hookdeck and Eventeer include.

Comparison

Eventeer Hookdeck Svix Convoy DIY queue
Receive provider webhooks Yes Yes Not documented Yes Yes, you build it
Send webhooks to your customers Partly Separate product (Outpost) Yes Yes You build it
Transform payloads No Yes Yes Not documented Yes, in your code
Devices or feeds over WebSocket Yes Not documented Not documented Not documented You build it
Self-hosting No Partly (Outpost only) Yes Yes (listed on its site) Yes
Stored events with replay Yes Yes Not documented Not documented You build it

“Not documented” means the pages listed under Sources do not say, not that the feature is absent.

When to stay with Hookdeck

Stay with Hookdeck if you need to transform, filter and deduplicate events in flight with JavaScript before they reach your service. Stay if you develop locally and rely on the CLI to forward webhooks to localhost. Stay if you want isolated queues and delivery rates per tenant (delivery groups), or an open source outbound service (Outpost, which is Apache-2.0 and self-hostable). Nothing about Eventeer replaces those.

Moving to Eventeer

The full capability matrix is on the comparison page. The short version of a migration:

  1. List your Hookdeck sources and what each connection does. Note every transformation, because you will move that logic into your own service.

  2. Create a listener per source with the management API:

    curl -X POST https://app.eventeer.io/api/v1/listeners \
  -H "Authorization: Bearer $EVENTEER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"stripe-events","type":"webhook","auth_mode":"anonymous"}'

    Use hmac instead of anonymous if the provider signs requests, or token to require a secret token. The response includes the ingress_url.

  3. Create a destination for each service that received events, with listener_ids and an optional filter, via POST /api/v1/destinations.

  4. Point the provider’s webhook URL at the listener and send a few test events. Check them in the event list and the destination’s delivery log.

  5. Verify the X-Eventeer-Signature header in your service, then remove the Hookdeck connection.

Sources

Every statement about Hookdeck, Svix, Convoy, Amazon API Gateway and Amazon SQS in this post comes from these pages, last reviewed November 2026.

Related posts

Send your first event

Create an organization, add a listener and see every event stored and replayable. Choose a plan when you are ready for real traffic.

Get startedLog in