Migration guides
Overview
Three starting points, three guides — a hand-rolled or BullMQ worker, Svix self-hosted, or a signing-only verification library.
If you're reading this, you already have working webhooks — sending, receiving, or both. These guides aren't "why webhooks"; they're "how do I get from what I have to Postel without a rewrite." Each one takes a specific legacy shape, maps its concepts onto Postel's, and ends with what you'd give up by switching.
Pick your starting point
From BullMQ or a hand-rolled worker
A queue + worker doing manual HTTP POSTs, retry counters, and (probably) a home-grown signature.
From Svix self-hosted
Application / endpoint / message / message-attempt, mapped onto Postel's outbound API.
From a signing-only library
standardwebhooks or svix verify() to the Postel inbound gate.
What every guide covers
- A concept mapping table — the legacy term next to Postel's term, so you can find the equivalent instead of re-deriving it.
- Copy-paste migration steps, in the order you'd actually do them.
- An honest what you give up section. Postel is a library embedded in your app, not a service — some things a dedicated webhook platform does (a customer-facing portal, multi-region delivery) are explicitly out of scope. See Is Postel for me? if you haven't already read it.
Read next
- Sending & the outbox — the transactional contract these guides migrate you onto.
- Verify a signed request — the receiver recipe.
- Storage — pick where the outbox and audit trail live.