Durable event delivery
Events are written to PostgreSQL before fan-out begins, then delivered at least once. Operators can manually retry failed deliveries and replay full events.
Sparrow
Sparrow is an open-source, self-hosted webhook delivery server that persists events in PostgreSQL, fans them out to matching subscriptions, and delivers signed HTTP requests with classified retries. It is intended for teams building and operating their own event and webhook infrastructure.
Self-hosted webhook delivery with durable event processing
Sparrow is an open-source, self-hosted webhook delivery server for systems that need to publish events to multiple HTTP consumers. Applications register event types and webhooks, push event occurrences through the REST API, and let Sparrow fan them out to matching subscriptions.
The server persists events in PostgreSQL before delivery begins, signs outbound requests, records delivery outcomes, and applies classified retries with backoff. It combines the delivery service, worker pipeline, embedded dashboard, and API documentation in one Go binary, with PostgreSQL as the required database.
Core capabilities
Classified retries
Sparrow distinguishes retryable failures, including 5xx responses, timeouts, 429 responses, and refused connections, from permanent failures such as many 4xx, DNS, and TLS errors.
Signed webhooks
Every delivery is signed using Standard Webhooks conventions. HMAC-SHA256 is the default; individual webhooks can use Ed25519 instead. Secrets are envelope-encrypted at rest with AES-256-GCM.
Subscription controls and delivery records
The delivery pipeline supports per-subscription Go-template transforms, per-webhook rate limits, webhook health tracking, and an audit trail of delivery attempts.
Operational visibility
OpenTelemetry traces propagate through queue jobs, while structured logs and metrics can be exported through OTLP. The embedded dashboard shows delivery logs and per-webhook health.
Simple self-hosted architecture
The server is distributed as one Go binary with an embedded UI and PostgreSQL as its only core database dependency. River workers use the same database, and migrations run automatically at startup.
Practical use cases
Application event fan-out
A product or backend can publish events such as `order.created` or `invoice.created` once and let Sparrow fan them out to every matching consumer webhook, without implementing a separate delivery queue.
Consumer-managed webhook onboarding
Teams can expose a scoped, expiring consumer portal link so an individual consumer registers endpoints, browses the event catalog, and inspects or retries its own delivery logs without receiving an administrator API key.
Failure investigation and recovery
Operators can use the delivery records, error categories, webhook health, traces, and replay or retry controls to diagnose an unavailable or misconfigured receiver and recover delivery.
Event routing beyond HTTP
A source can publish verified Stripe or GitHub webhooks, while recipe and sink satellites can connect events to destinations such as Slack, Discord, PagerDuty, ntfy, ClickHouse, SMTP, S3/MinIO, or OTLP logging.
Local development and workflow testing
Developers can run the CLI listener or webhook.site during integration work, inspect signed envelopes, preview recipe transforms in the browser, and use the REST API or embedded documentation to test workflows.
Pros and Cons
Pros
- Events are persisted before fan-out, with at-least-once delivery, replay, and manual retry support.
- Retry behavior is classified by failure type instead of treating every delivery error the same way.
- Outbound requests support HMAC-SHA256 or Ed25519 signatures, with encrypted webhook secrets at rest.
- The core deployment avoids Redis, Kafka, and a sidecar queue: it uses one Go binary and PostgreSQL.
- OpenTelemetry tracing, OTLP exports, structured logs, metrics, and an embedded delivery dashboard support operational troubleshooting.
Cons
- Sparrow is self-hosted, so teams must operate the server and PostgreSQL database rather than using a vendor-managed service.
- The documented production setup requires configuration of database access and encryption keys; the no-secrets Compose configuration is intended for local evaluation.
- Private and metadata-network destinations are blocked by default, so local or internal delivery requires an explicit configuration change.
FAQ
How do you install Sparrow?
The documented local setup uses Docker Compose. Download the Compose file, run `docker compose up -d`, and open the web UI at `http://localhost:8080`. The Compose setup includes PostgreSQL and runs migrations automatically on startup. For production, the installation documentation says to configure a real encryption key and database rather than using the local evaluation defaults.
What is the basic Sparrow workflow?
Register an event type, register a webhook with one or more event names, and then POST an event to the relevant consumer endpoint. Sparrow persists the event, matches subscriptions, creates deliveries, and sends signed HTTP POST requests in the background. Delivery status can be checked through the API or the embedded UI.
How does Sparrow handle failed deliveries?
Sparrow delivers events at least once. Failed deliveries are classified into categories such as server errors, timeouts, rate limits, refused connections, DNS errors, and TLS errors. Retryable failures use exponential backoff, while permanent failures stop; operators can also retry deliveries manually and replay events.
How are webhook deliveries authenticated?
By default, deliveries use HMAC-SHA256 with a per-webhook secret and Standard Webhooks headers. A webhook can instead use Ed25519, which recipients verify with a public key. Webhook secrets are envelope-encrypted at rest with AES-256-GCM.
Can Sparrow deliver to local or private-network endpoints?
Sparrow blocks private and metadata IP addresses by default as SSRF protection. Local evaluation can enable private-network delivery with `SPARROW_ALLOW_PRIVATE_NETWORKS=true`; the documentation also notes that the evaluation Compose file already enables this setting.
Quick Facts
- Category
- Developer tool / webhook infrastructure
- Deployment
- Self-hosted Go server with PostgreSQL
- License
- MIT
- Runtime
- Go 1.27+ and PostgreSQL 15+ for source builds
- Delivery model
- At-least-once delivery with background workers
- API specification
- OpenAPI 3.1
Sparrow 대안
ByteAsk
ByteAsk is a terminal-first AI coding agent for C and C++ that edits repositories and verifies changes with the real compiler, debugger, sanitizers, and tests before showing a diff. It offers a free tier plus paid plans, with editor connectors and zero-retention handling described in the source.
Epherem
Epherem is a static security scanner for web apps built with AI coding tools such as Lovable, Bolt, v0, Replit, Cursor, and Claude Code. It checks source files and dependencies for common security mistakes, then provides categorized findings and suggested fixes without running the app.
CreateOS Sandbox
CreateOS Sandbox is an isolated compute environment for running code and agent workloads inside Firecracker micro-VMs. It is designed for workflows that need machine-level isolation, private networking between sandboxes, and programmatic control through SDK, CLI, or MCP.
GitBot
GitBot is a local browser-based workspace for creating reusable coding bots powered by Claude Code, Codex, or OpenCode. It helps developers run those agents across repository folders with persistent threads and configurable permissions.
hob
hob is an independent workspace for coding agents that keeps agent sessions, terminals, history, and follow-up work organized around the tools and providers you already use. It is aimed at developers who want local control over routing, history, and workspace structure rather than a bundled model stack.
Ably Chat
Ably Chat is a chat API platform for building custom realtime chat applications. It supports room-based messaging, typing indicators, presence, reactions, and message updates, with usage-based pricing options for different deployment stages.