Svix alternative: what to use instead, by job

Svix is a webhook sending service. Its documentation describes it as making “sending webhooks easy and reliable”: you publish events from your product, and Svix delivers them to the endpoints your customers register, with automatic retries, delivery logs and a white-label portal where those customers manage their own endpoints. Its site also refers to an open source webhooks server that can be self-hosted.

Last reviewed: November 2026. People who go looking for a Svix alternative usually do so for one of two reasons of fit, not price. Either they do not send webhooks to customers at all and actually need to receive and relay events, or they want something that Svix is not built around, such as devices on WebSockets or a self-hosted setup with a different shape. Which alternative is right depends on which job you have, so this post sorts them by job.

What to look for in a Svix alternative

Start with the questions that decide it.

• Do you send or receive? Sending webhooks to your own customers and receiving webhooks from providers like payment processors are different jobs. Most tools focus on one of them.
• Do your customers need a portal? If end customers must add endpoints and read delivery logs themselves, you need an embeddable, customer-facing UI.
• Do you have devices or browsers? Hardware that holds a WebSocket open, or dashboards that subscribe to a live feed, are not a webhook problem.
• Do you need storage and replay? Keeping events for a while and re-sending the ones that failed matters when a downstream service has an outage.
• Can you host it yourself? Some teams must run the software in their own infrastructure. Others want to avoid running anything.
• Is it a queue you would rather build? Sometimes a database table and a worker are enough. More on that below.

The alternatives

Eventeer

Eventeer is a hosted hub for events you receive and relay. It is not a like-for-like replacement for Svix, and we would rather say so up front.

What it covers:

• Inbound webhooks. Listener URLs with anonymous, token or HMAC authentication, Idempotency-Key deduplication, and JSON, text or form payloads up to 256 KB.
• Device WebSockets. Devices connect over WebSocket, acknowledge each event, and show online status and last seen. You can send messages back down through the API.
• WebSocket sources and streams. Eventeer can dial an external wss:// feed and reconnect with backoff, and browsers or services can subscribe to a stream. Live frames are at-most-once, and a client can reconnect with since to replay what it missed.
• Storage and replay. Events are kept for 7, 30 or 90 days depending on the plan. You can browse, filter and replay them to a destination.
• Delivery to your own services. Destinations receive events as POST requests signed with HMAC-SHA256 in an X-Eventeer-Signature header, at-least-once, with 8 retries over about 24 hours and a delivery log. See fan out one webhook to many endpoints and replay failed webhooks.
• Metrics and alerts on a JSON field, including “quiet for N minutes” alerts. See webhook monitoring and alerts.

What it does not cover:

• There is no customer-facing portal. Destinations are configured by people in your organization, not by your end customers.
• There is no self-hosting. Eventeer is a hosted service only.
• Outbound delivery is to destinations you set up, not a per-customer endpoint registry with event types.

It fits when the job is receiving, storing and relaying events, especially when devices or WebSocket feeds are involved. It does not fit when each of your customers needs to manage their own webhook endpoints.

Hookdeck

Hookdeck’s documentation describes two products that matter here.

The Event Gateway is for inbound webhooks. Sources receive HTTP requests and connections route them to destinations, with filters, JavaScript transformations, deduplication and delivery groups. Retries can be triggered manually or automatically, bookmarks let you replay specific requests, and a CLI forwards events to a local server. This is the closest match if your main job is receiving webhooks, and it has transformations that Eventeer does not.

Outpost is Hookdeck’s outbound product. It describes itself as “outbound webhooks infrastructure and an open-source implementation of Event Destinations,” delivering your platform’s events to endpoints your users choose, with at-least-once delivery, retries and fan-out. Besides plain webhooks it lists destinations such as AWS SQS, EventBridge, Kinesis and S3, GCP Pub/Sub, Kafka and RabbitMQ. It is Apache-2.0 licensed and can be self-hosted, Hookdeck also offers a managed version, and it documents a tenant portal that can be embedded in your product. That makes it a sending-side alternative to Svix that is both open source and available as a managed service.

Its pages we reviewed do not describe device WebSockets or browser streams.

Hook0

Hook0 is a webhooks-as-a-service platform for the sending job. Your app makes one API call per event and Hook0 handles delivery. Customers choose which event types they receive and can register several target URLs, retry schedules are configurable per subscription, and every delivery attempt is logged so you and your subscribers can search and replay. An embeddable portal gives subscribers a branded view of their webhooks. The server is public under SSPL-1.0 and can be run on your own infrastructure with Docker Compose or Kubernetes.

It fits if you want Svix’s sending model with a self-hosted, open source option. The pages we reviewed do not describe a receiving product or device WebSockets.

Convoy

Convoy’s documentation presents it as a platform for both sending and receiving webhook events. It mentions portal links that extend the dashboard to your customers, an SDK and API, and API-driven provisioning of organisations, projects, sources, endpoints and subscriptions, including bulk endpoint onboarding. The documentation index we reviewed says little else, so check its docs directly for retries, replay and licensing before deciding.

Building it yourself on a queue

A table of pending deliveries, a worker, exponential backoff and an HMAC signature header will get you a basic sender. It is a reasonable choice for a handful of internal consumers. The cost shows up later: per-endpoint failure isolation, a delivery log people can read, replay, secret rotation and, if customers are involved, a portal. If you only need to receive and relay, building it means re-implementing storage, retries and replay that a hosted hub already has.

Comparison

Capability	Eventeer	Svix	Hookdeck	Hook0
Sends webhooks to your customers	Partly (destinations you configure)	Yes	Yes (Outpost)	Yes
Customer-facing portal	No	Yes	Yes (Outpost)	Yes
Receives inbound webhooks	Yes	Not documented	Yes (Event Gateway)	Not documented
Device WebSockets and streams	Yes	Not documented	Not documented	Not documented
Self-hosting	No	Yes	Partly (Outpost)	Yes

“Not documented” means the pages we reviewed do not describe it, not that it is impossible. Convoy is left out of the table because the page we reviewed was too brief to fill the rows fairly. For a longer matrix between two products, see Eventeer vs Svix.

When to stay with Svix

Stay with Svix if your product sends webhooks to your customers and they need to manage endpoints and read delivery logs themselves. Its portal exists for exactly that, and Eventeer has nothing equivalent. Stay too if you need to self-host, or if you rely on payload transformations, per-endpoint throttling or streaming events to storage buckets, all of which Svix lists on its site and Eventeer does not offer.

The two are not exclusive. You can send customer webhooks through a sender and use a separate hub for the events that come in.

Moving to Eventeer

This applies if you used Svix, or something like it, to receive webhooks. If you send to customers through Svix, leave that part where it is.

1. Create an organization and an API key, then create a listener for each provider that posts to you: POST /api/v1/listeners with {"name":"orders","type":"webhook","auth_mode":"hmac"}. The response includes the ingress_url.
2. Create the listener’s signing secret with POST /api/v1/listeners/:key/credentials and {"kind":"hmac_secret"}, and give it to the provider. The plaintext secret is returned once.
3. Point the provider at the new ingress_url. Keep the old endpoint running until events appear in the event list.
4. Create a destination with POST /api/v1/destinations that forwards matching events to your service, and check GET /api/v1/destinations/:key/deliveries.
5. Verify the X-Eventeer-Signature header on your side, as described in verifying webhook signatures, then retire the old endpoint.

Sources

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

• Svix home page
• Svix documentation introduction
• Hookdeck Event Gateway documentation
• Hookdeck Outpost overview
• Hook0 home page
• Convoy documentation