Best Open-Source Webhook Tools: Servers, Gateways, and Libraries Compared

The best open-source webhook tool depends on which job you need done. To send webhooks to your customers, self-host a delivery server: Hookdeck Outpost (Apache 2.0) or Svix Dispatch (MIT), or the source-available Hook0 (SSPL) and Convoy (Elastic License 2.0, which also receives). To run a script when a webhook arrives, use adnanh/webhook or webhookd. To test webhooks on your laptop, use the Hookdeck CLI, or self-host webhook.site. To add retries inside your own code, use your job queue's retry policy. Hookdeck Event Gateway, Hookdeck's managed product for receiving webhooks, is not open source.

Open-source webhook tools at a glance

Servers for sending webhooks to your customers

These are the tools to look at if your product needs to offer webhooks. Each one accepts an event from your application through an API, fans it out to every subscribed customer endpoint, signs the request, retries failures, and records each attempt. Our webhooks-as-a-service comparison covers the managed versions of the same four tools, with pricing.

Hookdeck Outpost

Outpost is Hookdeck's open-source outbound webhook and event delivery service, written in Go and licensed under Apache 2.0. It delivers to 11 destination types: webhooks, AWS SQS, S3, EventBridge, and Kinesis, GCP Pub/Sub, Azure Service Bus, RabbitMQ, Kafka, Cloudflare Queues, and Hookdeck Event Gateway (destination list).

• Dependencies: Redis, PostgreSQL or ClickHouse for the delivery log, and one message queue you already run: RabbitMQ, NATS JetStream, AWS SQS, GCP Pub/Sub, or Azure Service Bus (architecture). You bring the queue, so Outpost fits into infrastructure you already operate.
• Retries: exponential backoff with a 30-second base interval and up to 10 retries by default, or a custom schedule such as 30,60,300,900,3600 (event delivery docs). Failed attempts can be retried by hand through the API or the customer portal.
• Signing: HMAC-SHA256 in an x-outpost-signature header by default, or Standard Webhooks headers if you switch modes. Secret rotation sends both signatures during the overlap (webhook destination docs).
• Multi-tenancy and portal: every customer is a tenant with its own destinations, and a tenant portal lets customers manage endpoints and retry failed deliveries. A JWT-authenticated API covers teams that want to build their own UI.
• Same code, managed or self-hosted: the managed Outpost on Hookdeck runs the same codebase. There is no separate open-source edition with features removed.

Outpost leaves out transformations, FIFO ordering, and per-tenant throttling on purpose. The overview explains why: those features push the architecture toward something complex and expensive, and destinations like SQS and Kafka let your customers control throughput on their side.

Read more: Hookdeck Outpost alternatives

Svix Dispatch

The Svix server is the open-source version of Svix Dispatch's hosted webhook sending service. It is written in Rust, and is MIT licensed.

• Dependencies: PostgreSQL is required; Redis 6.2+ is optional and used as a task queue and cache (README).
• Retries: the hosted service makes eight attempts over about 28 hours: immediately, then after 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, and 10 hours.
• Signing: HMAC-SHA256 with svix-id, svix-timestamp, and svix-signature headers. Standard Webhooks, which Svix started, uses the same format with a webhook- prefix.
• Destinations: HTTP endpoints. Queues such as SQS and RabbitMQ need Svix Bridge, a separate component.

The trade-off to know about: Svix's README says that "some of the features, optimizations, and behaviors supported by the hosted dispatcher are not yet available in this repo." It does not list which ones, so test the specific features you need against the open-source build before you commit.

Read more: Svix Dispatch alternatives | Hookdeck Outpost vs Svix Dispatch

Hook0

Hook0 is a webhooks-as-a-service platform written in Rust and published under the Server Side Public License v1. You can read, run, and modify the code, but SSPL is not an OSI-approved licence, and it puts conditions on offering the software as a service to others. The README also asks that you not circumvent its licence-key functionality.

• Dependencies: PostgreSQL 18 or later is the only supported database (README).
• Retries: 3 seconds, 10 seconds, 3 minutes, 30 minutes, 1 hour, 3 hours, 5 hours, then every 10 hours, with jitter. Retries stop after 24 attempts or 8 days, whichever comes first.
• Signing: an X-Hook0-Signature header containing a timestamp, the list of signed header names, and a hex HMAC-SHA256.
• Destinations: HTTPS endpoints only.

Read more: Hook0 alternatives | Hookdeck Outpost vs Hook0

Convoy

Convoy is a webhook gateway written in Go that handles both sending and receiving in one deployment. It was MIT licensed until August 2024, when it moved to the Elastic License 2.0. ELv2 is source-available: you can self-host it, but you cannot offer it to others as a managed service, and it is not OSI-approved. The free Community edition covers the core gateway (incoming and outgoing webhooks, retries, and message broker support); features such as RBAC, white-labelling, and JavaScript transformations need a paid licence key (Premium self-hosted is $999/month).

• Dependencies: PostgreSQL and Redis. A PostgreSQL-only queue exists but the README marks it as experimental and licensed.
• Retries: linear or exponential backoff with jitter, configured per project and overridable per subscription.
• Signing: HMAC in an X-Convoy-Signature header, with a choice of hash and encoding per project, and an "advanced" timestamped format that supports rolling secrets.
• Destinations: HTTP endpoints only.

Read more: Convoy alternatives for sending webhooks | Hookdeck Outpost vs Convoy

Servers that run a script when a webhook arrives

Many "open source webhook server" searches are looking for something simpler: a small process that listens for a webhook and runs a command, such as redeploying when GitHub sends a push event.

• adnanh/webhook (MIT, Go) describes itself as a "lightweight incoming webhook server to run shell commands." You define hooks in a JSON or YAML file, with rules that match on headers or payload fields and pass values to your script as arguments or environment variables.
• webhookd (MIT, Go) maps URL paths to scripts in a directory and streams the script's output back in the HTTP response. It suits teams who want to add a hook by dropping a file into a folder.

Neither tool queues events, retries failed scripts, or keeps a searchable history. They work well for internal automation. For production webhooks from providers like Stripe or Shopify, where a dropped event costs money, you need a queue in front of your handler: either one you build or a managed gateway such as Hookdeck Event Gateway.

Tools for testing webhooks locally

• Hookdeck CLI (Apache 2.0) forwards webhooks from a public URL to your local server, with a terminal UI for inspecting and replaying events. It works without an account: running hookdeck listen creates a temporary guest account. The CLI is open source, but the public URL is served by Hookdeck's hosted service.
• smee.io (MIT server, ISC client), built by the GitHub Probot team, relays payloads to your machine over Server-Sent Events. Its README says it is meant for development, not production. You can deploy your own smee server.
• webhook.site (MIT) gives you a URL that captures every request so you can inspect it. You can self-host it with Docker. The open-source build lacks features of the hosted service such as Custom Actions, according to its README.

For a wider comparison, including tools that are not open source, see best webhook testing tools for local development.

Libraries, not servers

Sometimes the right open-source tool is a library inside your existing app.

• Signing and verification: the Standard Webhooks libraries (MIT) implement one signing scheme in C#, Elixir, Go, Java, JavaScript, PHP, Python, Ruby, and Rust. The spec defines three headers, webhook-id, webhook-timestamp, and webhook-signature, and supports HMAC-SHA256 and ed25519 signatures. Outpost and Svix Dispatch can both send this format.
• Retries from your job queue: Celery (Python, BSD), Sidekiq (Ruby, LGPL for the open-source edition), and BullMQ (Node.js, MIT) each let you retry a failed HTTP call with backoff. Our guides to each one show where their retry policies run out for webhooks.
• Framework packages: for example, spatie/laravel-webhook-server (MIT) signs and sends webhooks from a Laravel app through its queue.

Library or service?

A retry library is enough while you deliver to a few endpoints that you control. Your own services return predictable errors, you can read their logs, and if something fails for a day you fix it yourself.

A delivery service becomes worth running once your customers own the endpoints. At that point you need:

• Retries per customer, so one customer's broken endpoint doesn't hold up everyone else's deliveries
• A delivery log your support team can search when a customer says "we never got that event"
• Manual replay, ideally something the customer can trigger themselves from a portal
• Endpoint management: secrets, rotation, topic subscriptions, and auto-disabling endpoints that keep failing
• Signing that your customers can verify with an off-the-shelf library

Building those on top of Celery or BullMQ is possible, and many teams start that way. The webhook retry best practices guide covers the retry logic itself; the rest is the infrastructure Outpost, Svix, Hook0, and Convoy already provide.

What self-hosting costs

Self-hosting removes the licence fee and adds operating costs. Before you self-host, cost out three things.

Dependencies. Every sending server here needs PostgreSQL (or ClickHouse, for Outpost's log store), and most need Redis. Outpost also needs a message queue.

Upgrades. All four sending servers are under active development.

On-call. Webhook delivery is customer-facing. When your Redis fills up or your queue backs up at 3 a.m., your customers' integrations stop, and your team is the one paged. If nobody on the team wants that pager, the managed version of the same tool is usually cheaper than the engineering time.

Where Hookdeck Outpost fits

Outpost is the open-source option to pick if you want an OSI-approved licence, delivery to queues and streams as well as HTTP, and the freedom to move between self-hosted and managed without changing your integration.

• Apache 2.0, with no licence key, user limit, or feature gate on the self-hosted build
• Bring your own message queue: RabbitMQ, NATS JetStream, SQS, Pub/Sub, or Service Bus
• 11 destination types, so customers who don't want to run an HTTP endpoint can receive events in their own SQS queue, Kafka topic, or S3 bucket
• The same API managed or self-hosted: start on your own infrastructure and move to managed Outpost ($10 per million events, first 50,000 free) later, or the other way round

To try it, follow the Docker quickstart, which runs Outpost with RabbitMQ or SQS in Docker Compose. There are also quickstarts for Kubernetes and Railway.

Further reading

• Webhooks as a service: sending providers compared
• Hookdeck Outpost alternatives
• Best webhook infrastructure platforms
• Outbound webhook retry best practices