Svix

Svix is a webhooks-as-a-service platform, and svix-webhooks is the fully open source, self-hostable version of the exact same Rust server that powers Svix’s own commercial cloud offering. Instead of every SaaS company reinventing outbound webhook delivery — retries, HMAC signing, endpoint management, delivery logs — teams can run svix-server themselves or use official SDKs to talk to a hosted instance, with no functional gap between the two.

The repository is a large monorepo centered on svix-server, an axum-based Rust API backed by PostgreSQL (via sea-orm) and a pluggable message queue (Redis, Redis Cluster/Sentinel, or RabbitMQ through the omniqueue crate). A dedicated async worker drives delivery attempts with jittered exponential backoff, disables endpoints after repeated failures, and reports status through operational webhooks. Around the server sit svix-bridge, an agent that wires Kafka or other queues directly to webhook delivery or ingestion without a custom receiver, and svix-cli, an npm-distributed CLI for scripting the API.

On the client side, Svix maintains eight officially supported SDKs (Go, Python, TypeScript/JavaScript, Java, Kotlin, Ruby, C#, PHP) plus a native Rust crate and a Terraform provider, all generated from a shared OpenAPI schema via the codegen pipeline. Every SDK ships the same signature-verification logic, implementing the vendor-neutral Standard Webhooks specification that Svix helped create — so the same verification code can validate webhooks from any Standard Webhooks-compliant sender, not just Svix.

The project is MIT licensed with no enterprise fork or feature gating: there’s no ee/, enterprise/, or pro/ directory, and no license-check gating found in the server source, so everything in the self-hosted build is available with no license key required.

What You Get

• A standalone Rust webhook delivery server (svix-server) deployable via Docker/Docker Compose, backed by PostgreSQL and a pluggable Redis or RabbitMQ queue
• Eight officially maintained client SDKs (Go, Python, TypeScript/JavaScript, Java, Kotlin, Ruby, C#, PHP) plus a native Rust crate, all generated from a shared OpenAPI spec
• svix-cli, a standalone CLI published on npm for scripting the API without writing integration code
• svix-bridge, a companion agent that connects message queues (Kafka and others) directly to webhook delivery or receipt without a custom receiver server
• Built-in HMAC-SHA256 signature verification implementing the vendor-neutral Standard Webhooks spec, so it can also verify webhooks from other compliant senders
• Automatic delivery retries with exponential backoff and jitter, endpoint auto-disable on repeated failure, and operational webhooks reporting delivery status changes
• A Terraform provider for managing Svix applications and endpoints as infrastructure-as-code

Common Use Cases

• SaaS platforms that need to notify customer systems of events (payments, user actions, data changes) without building retry and signing infrastructure themselves
• Companies replacing an in-house webhook system with a battle-tested, self-hosted engine while retaining full control over their data
• Bridging existing Kafka or RabbitMQ event streams straight to external webhook endpoints via svix-bridge, without a dedicated receiver service
• Multi-tenant platforms that need per-application and per-endpoint event-type filtering, delivery observability, and JWT-scoped access
• Teams standardizing on the vendor-neutral Standard Webhooks specification so webhook verification code is interoperable across providers

Under The Hood

Architecture Svix-server is a layered Rust service built on axum with aide for OpenAPI generation: an HTTP layer (endpoints for applications, endpoints, event types, messages, attempts, and auth) sits atop a core domain layer (security/JWT permissions, cryptography, message-app assembly, operational webhooks, retry logic) which talks to a sea-orm/PostgreSQL data layer and a pluggable queue abstraction supporting Redis and RabbitMQ through the omniqueue crate. Message delivery is driven by an async worker that dequeues delivery tasks, builds signed HTTP requests through a dedicated webhook HTTP client, and re-enqueues failures with jittered backoff, while a separate background loop reaps expired data independently. The separation of concerns is clean — swapping the queue backend only touches the queue module — though the endpoint/application/message-destination path is fairly deep, so changing the core delivery task contract has a wide blast radius across the worker, queue producers, and several endpoint handlers.

Tech Stack The server runs on Rust with axum for HTTP and aide for typed OpenAPI/Redoc generation, sea-orm plus sqlx over PostgreSQL for persistence with embedded schema migrations, and a queue layer that can target Redis (with cluster and sentinel support), RabbitMQ, or an in-memory backend through the shared omniqueue crate. Authentication is JWT-based, supporting HMAC and RSA/EdDSA signing schemes. Observability runs through OpenTelemetry with OTLP export and optional Sentry error reporting, and outbound HTTP delivery uses a hyper/reqwest stack with TLS and async DNS resolution. Deployment targets Docker via an official server image with Compose for local Postgres and Redis, and the wider monorepo layers on a Rust bridge agent for queue integrations plus an OpenAPI-driven codegen pipeline that emits SDKs across eight languages and a Terraform provider.

Code Quality Testing leans heavily on an integration-test suite that exercises the API end-to-end against real Postgres and Redis/RabbitMQ instances, covering applications, endpoints, event types, messages, attempts, auth, operational webhooks, and background migrations, alongside a more modest set of inline unit tests for narrower logic. Error handling is explicit and centrally typed rather than swallowed, naming follows conventional Rust style, and the core crate forbids unsafe code and enables comprehensive lint warnings. CI is extensive and split by surface, with dedicated pipelines for the Rust server, security scanning, and separate lint/release workflows for every client SDK language and the bridge component, backed by a pre-commit configuration and dependency/license auditing.

What Makes It Unique Svix’s differentiator isn’t the application/endpoint/message data model — that’s standard for any webhook-as-a-service — but that it authored and open-sourced the underlying wire protocol: its signing code sends and verifies HMAC signatures under both Svix-branded headers and the vendor-neutral header names defined by the Standard Webhooks specification, so any consumer using a Standard Webhooks-compliant verification library can validate messages from other providers, not just Svix. svix-bridge is the other distinguishing piece, letting teams skip building a webhook receiver entirely by wiring queue messages directly to outbound delivery, or inbound webhooks straight into a queue, through declarative configuration. Neither idea is unique in isolation, but pairing a fully open, license-identical self-hosted server with a standards-first signing format is uncommon among webhook infrastructure vendors, most of whom keep the self-hosted version behind a paywall or feature gate.

Self-Hosting

Licensing Model MIT licensed — all features available in self-hosted deployments with no restrictions or license keys required.

Self-Hosting Restrictions None found. No ee/, enterprise/, pro/, or cloud/ directories exist in the repository, and no license-check or feature-gating logic (license_check, requiresLicense, isPro, isEnterprise) was found in the server source. The self-hosted server is the same codebase Svix runs for its commercial cloud service.

Enterprise Features Not applicable — no paid-tier feature split was found in the open source code.