Send webhooks reliably from your infrastructure. Retries, cryptographic signing, health tracking, payload transforms, recipes for Slack/Discord/PagerDuty, and a self-service portal — in one Go binary with PostgreSQL as the only dependency. Free, MIT.

Hi Product Hunt — I'm Sarath, and I built Sparrow because I kept building the same webhook delivery layer at every company I worked at, and it was never the fun part. Every team I joined needed to send webhooks: retries, signing, health tracking, a way for customers to manage their endpoints. Every time, we'd either pay a per-message vendor (and route our customers' data through someone else's infrastructure) or bolt together a queue, a worker fleet, Redis, a retry scheduler, and a monitoring stack. Both paths cost more than they should. Sparrow is what I wished existed: a single Go binary that does the whole job with PostgreSQL as its only dependency. No Redis, no message broker, no sidecar workers. River handles the job queue inside Postgres, so your backup is your backup and your monitoring is your monitoring. What ships in 1.0: At-least-once delivery with classified retries (10 error categories, each with a retry decision) Standard Webhooks signing (HMAC-SHA256 + Ed25519) AES-256-GCM envelope encryption for secrets at rest Per-endpoint health tracking with auto-disable that holds deliveries, never drops them Go-template payload transforms with 37 built-in functions — plus optional AI drafting (works with Anthropic, OpenAI-compatible, or your own local model) Shipped recipes for Slack, Discord, PagerDuty, ntfy, ClickHouse, Twilio, SendGrid, CloudEvents A self-service consumer portal (embeddable, token-scoped) A CLI with local listen, push, recipe management, and an MCP server for AI agents OpenTelemetry traces + metrics + logs, and a Prometheus /metrics endpoint Semver compatibility promise: the REST API, CLI, env vars, signatures, and template functions are frozen for the 1.x line It is MIT licensed. All features are in the open codebase — there is no enterprise edition. What's next: first-party client SDKs (right now you generate from the OpenAPI spec), horizontal scaling documentation, and more recipes. I'd genuinely like to know: if you run webhooks today, what's the part that hurts most? The retry logic, the customer-facing portal, the payload shaping, something else? That's what I want to make better next.

Hi! Congrats on the launch! I'm curious if you did some stress tests or have some idea what are the limits of Sparrow - would that be the limits of your Postgres? Basically trying to get a feeling how much load it can handle reliably.

@xfor thank you . I did run couple of benchmark run after iterations and wrote about it here https://sarathsp06.github.io/sparrow/blog/benchmark-four-walls/

Sparrow

Self-hosted webhook delivery. One binary, just Postgres.

Self-hosted webhook delivery. One binary, just Postgres.