# Why Postel Most teams reach for webhooks expecting a weekend feature and find a long tail instead: retries, replay, key rotation, idempotency, multi-secret windows, JWKS, raw-bytes preservation. Postel exists to absorb that tail — as a library you embed, not a service you operate. This is the long-form rationale. For a 30-second fit check, use [Is Postel for me?](/docs/get-started/is-postel-for-me) instead. ## The problem [#the-problem] Teams who need outbound webhooks today choose between: * **A hosted service** — Svix, Hookdeck Outpost — solves the problem comprehensively but adds operational footprint (Postgres + Redis + a separate dispatcher process), and hosted pricing jumps from a free tier straight to $490/mo. * **A hand-rolled worker** on Sidekiq, Oban, or BullMQ — the queue handles retries; everything else (signing, idempotency, replay, key rotation, JWKS, multi-secret windows, dedup, raw-bytes preservation) is reimplemented every time. The [Standard Webhooks](https://www.standardwebhooks.com) specification covers the wire format and ships signing helpers in nine languages, but explicitly leaves delivery, retry, key management, replay, and operational tooling to implementers. There's a gap between *"signs and verifies"* and *"production-grade delivery layer"* that the consortium doesn't fill. Postel sits in that gap. ## The positioning [#the-positioning] > Svix is for when webhooks are your **product**. > Postel is for when webhooks are a **feature** of your product. Postel does not compete with Svix or Hookdeck on customer-facing webhook portals, multi-region delivery, or 99.999% uptime SLAs. It targets a different audience: teams who want to add reliable outbound webhooks to an existing application without standing up a separate service, and single-binary OSS products that cannot run a Postgres + Redis + service sidecar in the first place. The full product-by-product table — Svix, Hookdeck Outpost, Convoy, DIY — lives on the [comparison page](/docs/project/comparison), including what Postel deliberately doesn't do. If you need a customer-facing portal, multi-region delivery, or five-nines SLAs, use Svix; Postel won't grow into them. ## Four design choices [#four-design-choices] ### 1. Library, not service [#1-library-not-service] Postel runs inside the host application against the host application's existing relational database (Postgres, MySQL, SQLite, …). Outbox inserts join the host's existing transaction — `send()` commits or rolls back atomically with the host's business writes. The transactional-outbox guarantee without extra connections, brokers, or a sidecar process. This is the inverse of Svix's bet. Svix wins when webhooks are the product and the operational footprint of a separate service is justified. Postel wins when adding webhooks to an existing app is a feature one engineer should be able to ship in an afternoon. Postel will never have a hosted offering, never run a separate dispatcher process, never require Redis or a message broker, never ship a customer-facing portal as a packaged product. If you need any of that, use Svix or Hookdeck Outpost. ### 2. Conformance, enforced [#2-conformance-enforced] The reliability and security guarantees Postel makes have to hold across every port — TypeScript today, Go and Python and Rust tomorrow. That requires more than docs. Every behavior — sender, receiver, retry, replay, dedup, key rotation — is captured as a testable scenario, and the cross-port contract is enforced by a **compliance test suite** ([`@postel/compliance`](https://github.com/postel-sh/postel/tree/main/compliance)) that runs against any HTTP receiver claiming Standard Webhooks compliance. Every Postel port passes the same suite at the same version before it can ship. The suite is the boundary between **CONTRACT** (everything every port must do) and **PORT-SPECIFIC** (mechanism each port is free to choose). What the suite tests is contract; what it doesn't is implementation detail. See [Reference → Specs & standards](/docs/project/specs). ### 3. Polyglot from the start [#3-polyglot-from-the-start] The TypeScript port ships first because Node + Postgres is the largest existing footprint and the receiver story is the smallest plausible cut. But the contract is language-agnostic: the wire format is AsyncAPI 3.0, the DB schema is SQL DDL, the capability behaviors are markdown specs, and the compliance suite drives any conformant receiver. Go, Python, and Rust ports follow on the same schedule, each gated on passing the suite. See [Polyglot](/docs/project/polyglot). The bet: a small narrow contract enforced by the compliance suite scales further than per-port reinvention or single-language lock-in. ### 4. Standard Webhooks-aligned, not divergent [#4-standard-webhooks-aligned-not-divergent] Postel implements the [Standard Webhooks](https://www.standardwebhooks.com) wire format end-to-end. The HMAC v1 signature scheme works unchanged. Ed25519 (`v1a`) for asymmetric verification is a Postel extension layered on top — additive, never breaking. JWKS publication is a one-liner. The `webhook-spec-version` header signals capability without breaking older receivers. When we deviate, we do so via the multi-secret rotation window: producers can sign with both old and new keys during overlap, and receivers accept either. No flag day. ## Governance, in one paragraph [#governance-in-one-paragraph] MIT-licensed OSS with no open-core: every feature in the capability specs ships in the open, forever — funding (sponsorships, support) never feature-gates. Maintainer-led, public roadmap, and the compliance suite as the binding contract. The full operating principles and the 1.0 definition-of-done live in [VISION.md](https://github.com/postel-sh/postel/blob/main/VISION.md), which is the governing document — this page is the adopter-facing summary. ## Read next [#read-next] * [Comparison](/docs/project/comparison) — Postel vs Svix vs Outpost vs Convoy vs DIY, product by product. * [Design decisions](/docs/project/decisions) — the ADR index: why the API is shaped this way. * [Is Postel for me?](/docs/get-started/is-postel-for-me) — the fast filter. * [Polyglot](/docs/project/polyglot) — the language-port roadmap. * [Specs & standards](/docs/project/specs) — the source-of-truth artifacts.