Svix
Open-source webhooks service — send events to your customers with retries, signing and a delivery history
Svix is an open-source, self-hostable service for sending webhooks to your own customers: you make one API call and it handles delivery, retries, payload signing and the per-endpoint history. It is MIT-licensed, written in Rust, and had 3,376 GitHub stars as of August 2026. For a small team it turns "we should support webhooks" from a fortnight of queue plumbing into an afternoon — which matters more than it sounds, because outbound webhooks are the cheapest integration surface you can offer, and integrations are distribution.
What Svix is
Svix (github.com/svix/svix-webhooks) is the open-source dispatcher behind the hosted Svix service. Your application makes one API call to send a message to an application's endpoints; Svix owns everything after that. It runs from the repo's own Docker Compose file, which also starts the two dependencies it needs: PostgreSQL for storage, and Redis — optional, version 6.2.0 or higher — for the task queue and cache. Official client libraries cover Go, Python, TypeScript, Java, Kotlin, Ruby, C#, Rust and PHP, plus a Terraform provider and a CLI you can run straight from npm.
- Signed payloads. Symmetric pre-shared keys by default; the README puts symmetric signing at roughly 50 times faster to sign and 160 times faster to verify than the ed25519 asymmetric option, which is also supported when you would rather hand out a public key than a secret.
- Retries and a dead-letter queue. Repeated internal errors land a task in a DLQ, and the README tells you to watch its depth via a dedicated metric and redrive it from an admin endpoint once the cause is fixed.
- SSRF protection. Dispatches to internal IP addresses are blocked by default, with a subnet allowlist for the case where the receiver really is internal.
- Operational webhooks. The server can send you webhooks about itself, so you find out that a customer disabled or changed an endpoint without polling for it.
The README is unusually straight about its own limits: the hosted service carries features, optimizations and behaviours that are not in the repo yet, and the two are described as mostly but not fully compatible. That is worth reading before you assume open-source parity.
Why webhooks are a growth surface, not just plumbing
Webhooks get filed under engineering, which is why they are always next quarter. That filing is a mistake. An outbound webhook is the one integration you build once and never build again: after it exists, your customers wire you into Zapier, n8n, their internal scripts and whatever else they already run, and each of those is a partnership you did not have to negotiate. Our page on whether integrations are worth building makes the fuller argument; webhooks are the cheapest row in that table.
- Distribution without partnerships One endpoint puts you inside every automation tool your customers already pay for, without shipping a connector for any of them.
- Retention you did not have to argue for A customer whose internal system reacts to your events has a switching cost that no feature comparison creates.
- A cheaper support surface "Why did it not fire" is answerable from a delivery log the customer can see, instead of from your own logs at 11pm.
- A reason to write documentation people actually read Event payloads are the rare docs that get bookmarked, which makes them a genuinely good page to rank.
What being on the receiving end taught us
We do not send webhooks at scale; we consume a lot of them, for payments and chat and every integration our agents touch. Two habits came out of that, and both are decisions you make on the sending side too. First: a receiver should answer 200 and record the event even when the feature that consumes it is switched off, because anything else makes the sender retry, and a retry storm is worse than an event you ignore. Second: every handler has to be safe to run twice, because the same event will arrive twice — that is not a bug in the sender, it is what at-least-once delivery means.
The mirror image on the sending side is the thing we got wrong elsewhere and would not repeat: a transport success is not an action success. We once recorded a post as published because the HTTP call returned 200, while the body underneath said it had been rejected. If you are the one sending webhooks, make the delivery record reflect what the receiver's body said, not what the status line said — and give customers the history so they can check you. Shipping webhooks does not by itself bring anyone; announcing them to the customers who asked, documenting the payloads, and getting listed where automation users look is the part that does. That half is the same growth work as everything else, which is what AgentCeres — the AI Growth Officer at agentceres.com — is for: the agents draft the announcement, the docs page and the outreach, and a person approves anything that goes out.
FAQ
- Is Svix free to self-host?
- Yes. The repository is MIT-licensed and the server runs from its own Docker Compose file with PostgreSQL, plus Redis if you want the Redis-backed queue and cache. The same company sells a hosted version, and the README is explicit that the open-source dispatcher does not have every feature and optimization the hosted service has — worth checking against your requirements rather than assuming they are the same product.
- Do I actually need Redis?
- Not necessarily — the README lists PostgreSQL as required and Redis as optional, used for the task queue and cache. If you do run it, two configuration notes from the README are easy to miss and expensive to learn: enable persistence so queued tasks survive a restart, and set the eviction policy so keys without an explicit expiry are never evicted.
- Symmetric or asymmetric signatures?
- Symmetric is the default and the recommendation. It is dramatically faster on both sides and much simpler for your customers to verify, at the cost of a shared secret per endpoint. Asymmetric ed25519 signing exists for the case where you would rather publish a public key than distribute secrets, which mostly matters when your receivers are third parties you do not have a support relationship with.
- Should I just build webhook sending myself?
- You can, and the first version is small. What grows is everything around it: exponential backoff, per-endpoint disabling after repeated failures, replay protection, secret rotation, a delivery history your customers can read, and a queue that does not lose events when the process restarts. That is the same build-versus-buy shape we wrote about in should I build my own AI marketing agent — the prototype is a weekend, the operating half is not.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.