# Is Postel for me?



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; run through it before you spend real time evaluating.

## Is *receiving* webhooks all you need? (today) [#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](/docs/get-started/quickstart).

## Is *sending* webhooks part of what you need? (today) [#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](/docs/storage) 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](https://www.svix.com/) or [Hookdeck Outpost](https://hookdeck.com/outpost) instead when webhooks are *the* product — a customer-facing portal, multi-region delivery, or a 99.999% SLA.

## Does your stack match? [#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](https://github.com/postel-sh/postel/blob/main/decisions/0001-library-shape.md)).                    |
| Framework adapters | Hono, Express, Fastify, NestJS, Next.js (Bun / Deno via the framework-agnostic factory) | + dedicated 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 [#the-six-line-filter]

Answer YES or NO to each. Mostly YES → Postel is a strong fit.

1. My app is on Node, Bun, or Deno (and I can wait for Go/Python/Rust ports). **YES / NO**
2. 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 `Storage` interface for another backend. **YES / NO**
3. I want webhooks to be a *feature* of my product, not the product itself. **YES / NO**
4. I want the receiver and sender to share the same transaction as my business writes. **YES / NO**
5. I'd rather run delivery inside my app process than operate a separate dispatcher service or a Redis / queue dependency. **YES / NO**
6. 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](https://www.svix.com/), [Hookdeck Outpost](https://hookdeck.com/outpost), or a hand-rolled queue worker.

## Read next [#read-next]

* [Postel vs Svix vs Outpost vs Convoy vs DIY](/docs/project/comparison) — the product-by-product table.
* [Why Postel](/docs/project/why) — the full positioning and design rationale.
* [Quickstart](/docs/get-started/quickstart) — verify your first webhook.
* [Polyglot](/docs/project/polyglot) — language-port roadmap.