Sparrow is a self-hosted webhook delivery platform built for teams that want full control over their webhook infrastructure. No per-message pricing, no vendor lock-in, no external dependencies beyond PostgreSQL.
Sparrow is MIT-licensed, and all core features are available in the open-source codebase (including envelope encryption, webhook signing, retries, and health tracking).
Production-Grade Delivery
At-least-once delivery with exponential backoff, 10-category error classification, per-webhook health tracking (healthy/degraded/unhealthy state machine), and automatic retry logic that distinguishes retryable failures from permanent ones.
Cryptographic Signing
Every delivery is signed in the Standard Webhooks format — HMAC-SHA256 by default, or Ed25519 per webhook for public-key verification. Ed25519 keypairs are generated automatically on opt-in.
Encryption at Rest
Webhook secrets, signing keys, and sensitive headers are envelope-encrypted with AES-256-GCM and per-record data encryption keys. Not just “encrypted in the database” — actual envelope encryption with key hierarchy.
Zero External Dependencies
PostgreSQL is the only infrastructure requirement. No Redis, no message broker, no object storage. The River job queue runs inside PostgreSQL. One database to back up, monitor, and scale.
Consumer Self-Service Portal
Hand each consumer a scoped, expiring link to a portal where they register their own endpoints, manage subscriptions, and inspect and retry their own deliveries — no admin API key, no visibility into anyone else’s data. One admin call mints the token; it is stateless (HMAC-signed, revoked by expiry) and rides in the URL fragment. This is the App Portal capability Svix is known for — built in, no extra service to run.
The table below compares Sparrow with the main alternatives for webhook delivery: Svix (open-source + cloud), Convoy (source-available, Elastic 2.0), Hookdeck (SaaS platform with open-source Outpost agent), AWS SNS (managed), and building it yourself (DIY).
| Capability | Sparrow | Svix | Convoy | Hookdeck | AWS SNS | DIY |
|---|---|---|---|---|---|---|
| Fully open source (MIT) | Yes | Partial (OSS core, paid features) | No (Elastic 2.0, source-available) | Partial (Outpost OSS, core platform closed) | No | Yes |
| Self-hosted | Yes | Yes | Yes | Partial (Outpost self-hosted, platform SaaS) | No (Managed) | Yes |
| No vendor per-message pricing (self-hosted) | Yes (self-hosted; infra only) | No | Yes (self-hosted) | No | No | Yes (your infra only) |
| Infra complexity (core deps) | PostgreSQL only | PostgreSQL (+ Redis for HA) | PostgreSQL + Redis | SaaS | Managed | Varies |
| Job queue backend | PostgreSQL (River) | Redis-backed queue/workers | Background workers + Redis | Managed | Managed | Varies |
| Webhook signing | Dual HMAC-SHA256 + Ed25519 | HMAC-SHA256 | HMAC-SHA256 | HMAC-SHA256 | X.509 signature (not HMAC) | Manual |
| Security model for secrets | Envelope encryption with per-record DEKs | Encrypted at rest (service-managed keys) | Deployment-dependent (no built-in envelope hierarchy) | Vendor-managed encryption | Vendor-managed encryption | Manual |
| Payload transformation | Go templates per subscription (37 functions, incl. structural + arithmetic) | Varies by edition/plan | Yes (JS transform) | Yes (JS transform) | No | Manual |
| Per-webhook rate limiting | Leaky bucket (DB-backed) | Available (details vary) | Yes | Yes | Regional quotas | Manual |
| Delivery semantics | At-least-once + explicit idempotency model | At-least-once + retries | At-least-once + retries | At-least-once + replay | At-least-once | Varies |
| Delivery health model | State machine (healthy/degraded/unhealthy) | Endpoint status | Circuit breaker | Dashboard metrics | CloudWatch | Manual |
| Error classification | 10 protocol-aware categories with retryability flags | Basic status and error reporting | Success/failure | Categorized | CloudWatch | Manual |
| Bulk retry/re-push | Deterministic snapshot-based (up to 10K) | Not in OSS | Manual retry | UI retry | No | Manual |
| Idempotent ingestion | Built-in dedup with idempotency keys | Application-level (no OSS ingest dedup) | Event IDs | Dedup available | Message dedup (5min) | Manual |
| REST / OpenAPI API | Yes (OpenAPI 3.1 spec) | Yes (REST) | Yes (REST) | Yes (REST) | No | Manual |
| Event schema validation | Soft validation (warns, never rejects; server-side check on test pushes) | JSON Schema defs (not enforced) | No | Filters (not schema) | No | Manual |
| Prebuilt integration recipes | Yes (Slack, Discord, PagerDuty, ntfy, ClickHouse, Twilio, SendGrid — one YAML, rendered server-side) | Limited | Limited | Yes (integrations) | Limited destinations | Manual |
| Inbound ingestion (verify provider signatures) | Yes (sparrow-sources: Stripe, GitHub, cron schedules) | Yes (Ingest product) | Yes (incoming webhooks) | Yes (core feature) | No | Manual |
| Non-HTTP delivery (email, object storage, OTLP) | Yes (sparrow-sinks: SMTP, S3/MinIO, OTLP logs) | Limited | Limited | Limited | SNS-native targets | Manual |
| Self-monitoring alerts | Built-in system events (webhook health, delivery failure) + opt-in email alerts | Operational webhooks | Alert configs | Issue alerts | CloudWatch alarms | Manual |
| CLI tooling | Yes (push, tail, local listen, apply recipes, debug templates) | Yes | Yes | Yes (localhost tunnels) | AWS CLI | Manual |
| Web dashboard | Embedded SvelteKit | Included | Included | Included | Console | No |
| Tracing & metrics | OpenTelemetry (traces + metrics + logs, job-level propagation) | Logging | Prometheus metrics | Dashboard | CloudWatch | Manual |
| SSRF protection | Built-in (private IPs, redirects) | Built-in controls (plus proxy best practices) | Built-in controls / IP filtering | Managed | N/A | Manual |
| Client SDKs | 3 (Go, Python, TypeScript) | Broad coverage | Multiple | Multiple | All AWS SDKs | 0 |
| Consumer app portal | Yes (embeddable, token-scoped) | Yes (embeddable) | Yes (Portal Links) | Yes (Outpost/managed) | No | No |
| Multi-region / HA story | PostgreSQL-native HA + stateless workers | Vendor/infra-managed | Vendor/infra-managed | Vendor-managed | Global managed service | Manual |
| Multi-tenant SaaS mode | No (single-tenant focus) | Yes | Yes | Yes | Yes | Manual |
Since Svix is the closest competitor architecturally, here’s a deeper look:
| Capability | Sparrow | Svix OSS |
|---|---|---|
| Event schema validation | Soft validation (warnings, never rejects) | JSON Schema defs (not enforced) |
| Consumer isolation | Built-in logical separation | Application-level |
| API protocol | REST/HTTP on :8080 (OpenAPI 3.1 spec) | REST API only |
| Deployment shape | Single binary + Docker image | Broader deployment options |
| Container image | Distroless (~15MB), non-root | Standard |
| Consumer self-service portal | Built-in, token-scoped — embed or hand off a link | App Portal (magic-link session) |
text/template transforms per subscription (37 built-in functions, including structural dict/list/merge/append and arithmetic) let you reshape payloads for different consumers (Slack, PagerDuty, custom formats) without proxy layers. This is a deliberate design choice over an embedded JavaScript runtime: templates are parsed once and cached, so each delivery runs with near-zero overhead; there is no per-worker JS VM to pool, no extra dependency, and the server stays a single distroless ~15MB binary with a small, predictable memory footprint. Parsed templates are concurrency-safe and reused across all delivery workers, so transform throughput scales with workers instead of contending on interpreter instances. Every transform is bounded by a 1MB output cap and a 5s execution timeout. Available to all users, not a paid feature.sparrow.webhook.health_changed, sparrow.webhook.delivery_failed) through the same pipeline it delivers with, and can email you about them via opt-in alert configs — your webhook infrastructure alerts on itself, no external monitoring stack required.dig, type coercion) cover payload reshaping without a scripting engine.Sparrow runs anywhere you can run one container and connect it to PostgreSQL: