Is Postel for me?
A six-line decision gate. Run through this before you spend more time evaluating.
Webhook libraries are not interchangeable. The right one depends on what you're building, where it runs, and what trade-offs hurt least. This page is a fast filter — not marketing, not positioning. Read it before the rest of the docs.
Is receiving webhooks all you need? (today)
If you only need to verify incoming webhooks from another service (Stripe, GitHub, Linear, your vendor's API), Postel's receiver is feature-complete and worth a look.
- ✅ Standard Webhooks compliant (verifies any producer that follows the spec).
- ✅ Multi-secret rotation, JWKS, structured errors, idempotency dedup.
- ✅ Zero runtime dependencies in the core package; tree-shakes.
- ⚠️ Production-ready code, but no release tag is cut yet, so nothing is on npm. Wait for the tagged release if you need npm-installable.
If yes, go to Quickstart.
Is sending webhooks part of what you need? (today)
If you need to deliver webhooks to your customers' endpoints — outbox, retries, replay, fanout — that's available too, with durable persistence on Postgres, MySQL, or SQLite.
- ✅ Transactional outbox that joins your business write — no broker, no dispatcher process.
- ✅ Retries, circuit breaker, dead-letter, first-class replay, endpoint lifecycle, secret rotation.
- ✅ Storage adapters for raw
pg/better-sqlite3/mysql2, or your existing Kysely / Drizzle / Prisma / TypeORM / MikroORM instance. - ⏳ External job-queue workers (BullMQ, PgBoss) and KMS-backed keys are config slots, not yet wired — the in-process worker pool is the supported runtime.
Reach for Svix or Hookdeck Outpost instead when webhooks are the product — a customer-facing portal, multi-region delivery, or a 99.999% SLA.
Does your stack match?
The library has a narrow scope on purpose.
| Property | Postel today | Postel v1.0 plan |
|---|---|---|
| Runtime | Node, Bun, Deno | Same + Go, Python, Rust (each at its own cadence) |
| Database | Postgres, MySQL, SQLite — standalone or via your ORM | The same families, including wire-compatible engines (MariaDB, PlanetScale, libSQL/Turso, …), plus any other backend via a custom Storage adapter |
| Broker / queue | None required. Uses your existing DB transaction. | Same. Will stay broker-free forever (ADR 0001). |
| Framework adapters | Hono, Express, Fastify, NestJS (Next.js / Bun via the framework-agnostic factory) | + dedicated Next.js, Bun, Deno, SvelteKit adapters |
| Hosting model | Embedded in your app | Same. Never a hosted service. |
If you need Redis-backed queues, a separate dispatcher service, multi-region replication, or a customer-facing webhook portal as a packaged product — Postel won't grow into any of those. Use Svix or Hookdeck Outpost.
The six-line filter
Answer YES or NO to each. Mostly YES → Postel is a strong fit.
- My app is on Node, Bun, or Deno (and I can wait for Go/Python/Rust ports). YES / NO
- My data store is in the Postgres, MySQL, or SQLite family — including a wire-compatible engine like MariaDB, PlanetScale, or libSQL/Turso — or I'll implement the
Storageinterface for another backend. YES / NO - I want webhooks to be a feature of my product, not the product itself. YES / NO
- I want the receiver and sender to share the same transaction as my business writes. YES / NO
- I'd rather run delivery inside my app process than operate a separate dispatcher service or a Redis / queue dependency. YES / NO
- I prefer a library I configure in code over a DSL or a hosted dashboard. YES / NO
If most of those are NO, you'll be happier with Svix, Hookdeck Outpost, or a hand-rolled queue worker.
Read next
- Why Postel — the full positioning, design choices, and what 1.0 means.
- Quickstart — verify your first webhook.
- Polyglot — language-port roadmap.