For decision makers

This page is for the people who approve things, not the people who deploy them. It answers the questions that come up in a security review, a vendor assessment, or a budget meeting, in that order. Each answer is short, and each one is backed by something you can verify in the code or the documentation.

Sparrow delivers webhooks: when something happens in your systems, it tells the other systems that need to know, reliably, with proof of who sent it. The decision in front of you is whether that job runs inside your infrastructure or on a vendor’s.

Why Sparrow, and not a hosted service or another open-source project?

Because the other two options each make you give something up, and Sparrow does not.

There are three ways to run webhook delivery. Here is what each one costs you.

A paid, hosted service. The vendor runs the operation, and in exchange the operation is theirs. Your event payloads, your customers’ endpoint URLs, the signing secrets that prove you are you, and the network path every delivery travels all sit on infrastructure you do not own and cannot inspect. You get a dashboard and an invoice. You also get a new processor on your data map, a sub-processor on your privacy notice, a per-message bill that scales with your success, and a dependency on a company whose pricing, roadmap and ownership can change without asking you.

The usual self-hosted platform. Now everything is yours, and that is where the trouble starts. The typical open-source webhook stack arrives as a convoy: a message broker, a cache, a scheduler, a separate worker fleet, sometimes a second database, each with its own version matrix, its own failure modes, its own security advisories and its own 3 a.m. page. Ownership is real, but it is bought with an operations burden that grows every time the project adds a dependency, and the team that inherits it spends more time keeping the convoy moving than delivering webhooks.

Sparrow. Everything stays with you, and keeping it running is trivial.

All yours. The binary runs in your network, the data sits in your database, the keys are held by you, and the delivery path is one you can trace end to end. There is no control plane, no phone-home, no vendor in the loop.
All open. MIT licence, every line readable by your security team, nothing held back for an enterprise tier, and a stack of open-source components all the way down.
All standards. Standard Webhooks signatures, OpenAPI 3.1, OpenTelemetry, CloudEvents. Every seam where you could be locked in is an open specification instead.
One dependency, and it is PostgreSQL. Not a broker plus a cache plus a queue. One database, the most widely deployed SQL database in the world, the one your team already runs, backs up, monitors and trusts. Queueing, scheduling, rate limiting, retry state and the audit trail all live inside it, using the same backup you already take and the same expertise you already have. A single Go process on top. Migrations run themselves on start. Upgrading is replacing a binary.

	Hosted service	Typical self-hosted	Sparrow
Who holds the data, keys and network path	The vendor	You	You
Who carries the operations	The vendor	You, across many moving parts	You, with one process and one database
Infrastructure dependencies	Opaque	Broker, cache, workers, database	PostgreSQL
Source you can audit	No	Usually	Yes, all of it, MIT
Price scales with volume	Yes	No	No
Can be withdrawn or repriced	Yes	No	No

The result is the combination the other two cannot offer: the sovereignty of self-hosting with an operational footprint smaller than most teams’ internal services. That is the case for Sparrow in one sentence. The rest of this page is the evidence.

Where does our data go?

Nowhere you did not put it. Sparrow is a single Go binary and a PostgreSQL database, both of which you run. Event payloads, customer endpoints, and secrets never leave your network unless you deliver them to a destination you chose. There is no control plane to call home to, no usage reporting, and telemetry export is off unless you turn it on (configuration).

For a regulated business this is the whole argument in one line: a hosted webhook vendor is a third party processing your data; a self-hosted one is not.

It removes a vendor from the picture, and it gives you the controls those frameworks ask for.

No new processor or business associate. Because the delivery layer runs inside your boundary, there is no vendor BAA or DPA to negotiate for it, no sub-processor to list, and no cross-border transfer created by the act of sending a webhook.
Encryption at rest, done properly. Webhook secrets, signing keys and sensitive headers are envelope-encrypted with AES-256-GCM: every record has its own data key, wrapped by a master key you hold. Keys live in a ring, so you can rotate them without downtime (how it works).
Encryption in transit is yours to enforce at your TLS termination point, the same way as any internal service.
Data minimisation and retention. A retention period purges old events and their delivery records on a schedule, so you keep what the policy says and nothing more.
Audit trail. Every delivery attempt is recorded with its outcome. For an immutable record, the S3 archive sink writes one JSON object per delivery to a bucket you control, which is the pattern auditors expect for payment and consent events (sinks).
Least privilege. API access is by master key or scoped tokens with expiry; customer-facing portal tokens are pinned to a single customer and cannot reach the admin API (access).

Why does the licence matter to the business?

Sparrow is released under the MIT licence. In practical terms:

You can use it for anything, commercially, internally, in products you sell, with no fee and no usage limits.
You can modify it, and you are under no obligation to publish your changes. There is no copyleft clause that could reach into your own code.
You can audit it. Every line that touches your data is readable by your security team. There is no closed component to take on trust.
Nobody can take it away. A vendor can change pricing, deprecate a tier, or be acquired. A copy of the source under MIT cannot be revoked. If the project stopped tomorrow, your deployment keeps running and you keep the right to maintain it.

All features are in the one open codebase. There is no enterprise edition holding back encryption, signing or audit features behind a contract.

Is the stack open all the way down?

Yes. Sparrow’s licence would mean little if it sat on a proprietary component, so there is none:

Go, the language and runtime, is open source (BSD licence) and maintained by Google and a large community.
PostgreSQL is the only infrastructure dependency: open source (PostgreSQL licence), available from every cloud provider and every distribution, with decades of operational knowledge behind it. There is no Redis, no message broker, no proprietary queue.
The web interface is built with Svelte (MIT).
Everything in between (the HTTP router, the API framework, the job queue, the database drivers, the telemetry libraries) is open source under MIT, BSD, Apache or MPL licences, which you can confirm from the dependency manifest in the repository.

Nothing in the stack carries a per-seat or per-node fee, and nothing in it can be relicensed out from under you.

Does it tie us to Sparrow’s way of doing things?

No. Wherever an open standard exists for the job, Sparrow uses it rather than inventing its own, so the pieces around it are interchangeable:

Standard Webhooks for signing and headers. Your customers verify deliveries with the same libraries they already use for other platforms.
OpenAPI 3.1 describes the entire API. Generate a client in any language, import it into your API gateway, or hand it to a contractor; it is a file in the repository.
OpenTelemetry for traces, metrics and logs, and a Prometheus endpoint for scraping. It plugs into whatever observability stack you run, not a vendor dashboard.
CloudEvents as an output format, when the receiving system speaks it.
Plain HTTP and JSON for every integration, and Go’s standard template language for payload transformation.

The practical effect is that Sparrow is replaceable by design. If you ever moved off it, the signatures, the API description, the telemetry and the event formats would all carry over.

Does it depend on AI?

No. Sparrow is AI-friendly, not AI-dependent.

Nothing in actual operation uses a model: receiving events, matching subscriptions, transforming payloads, signing, delivering, retrying and reporting all run without one. There is no AI in the critical path, and there is nothing to switch off before you can run it.

What “AI-friendly” means in practice:

The documentation ships an llms.txt, so your own AI assistants and coding tools can read it accurately.
One optional convenience: drafting a payload transform from a plain-language description. It is off until you turn it on (SPARROW_AI_ENABLED=true) and configure a provider, and it works with the Anthropic API or any OpenAI-compatible server, including a model you run inside your own network. Every draft is checked against a sample event before it is shown, and a person still reviews and saves it.

Leave it unconfigured and nothing else changes.

What does it cost?

The software costs nothing. You pay for a small compute instance and a PostgreSQL database, both of which most organisations already know how to run and already have under contract. There is no per-message, per-endpoint or per-seat pricing, so cost does not grow with success, and nobody has to forecast webhook volume to set a budget.

The honest cost is operational: someone owns the deployment, the database backups and upgrades. Sparrow is built to keep that small. One process, one dependency, migrations that run automatically on start, and standard Prometheus metrics and OpenTelemetry traces so it plugs into the monitoring you already have.

How do we know it is reliable?

Delivery is at-least-once, with retries that back off and that distinguish a failure worth retrying from one that is not. Each endpoint has a health state, so a customer whose system is down is detected and paused rather than hammered, and your team is alerted. Nothing is dropped silently: a delivery that cannot be made is recorded with the reason.

All of this runs on PostgreSQL, the most boring and best-understood database in the industry, which is a deliberate choice. There is no message broker or cache to operate, size, or explain to an auditor.

How do our customers know a webhook really came from us?

Every delivery is signed. Sparrow uses the Standard Webhooks format with HMAC-SHA256 by default, or Ed25519 public-key signatures per endpoint when a customer needs to verify without sharing a secret. This is the same scheme used by major payment and SaaS platforms, so your customers’ engineers already know how to verify it.

What happens if we want to leave?

Your data is in your PostgreSQL database, in plain tables, with an exported OpenAPI specification describing every operation. Event type definitions export and import as files. There is no proprietary format, and there is nothing to export from a vendor because there is no vendor.

Who is behind it, and what if they stop?

Sparrow is an open-source project with a public repository, public issue tracker and public release history. Because the licence is MIT, continuity does not depend on any one maintainer: your organisation, or a contractor, can carry it forward from the source you already hold. That is a materially stronger position than a hosted vendor, where the end of the company is the end of the service.

The short version

Question	Answer
Why not a hosted service?	Your data, keys and network would be theirs; the bill grows with volume.
Why not another self-hosted platform?	Brokers, caches and worker fleets to run; Sparrow needs only PostgreSQL.
Where is our data?	In your network, in your PostgreSQL.
Is there a new vendor to assess?	No. There is nothing to send data to.
Secrets at rest?	AES-256-GCM envelope encryption, rotatable keys you hold.
Proof of origin?	Standard Webhooks signatures, HMAC-SHA256 or Ed25519.
Licence?	MIT. Use, modify, keep private, cannot be revoked.
Open dependencies?	Go, PostgreSQL, Svelte; everything under MIT, BSD, Apache or MPL.
Open standards?	Standard Webhooks, OpenAPI 3.1, OpenTelemetry, CloudEvents.
Depends on AI?	No. Nothing in operation uses a model; one optional drafting aid, off by default.
Cost?	Compute and a database. No per-message fees.
Lock-in?	None. Plain tables, OpenAPI spec, open source.

If the security team wants the detail behind these answers, send them to the security reference and the deployment security guide.