Compare
dotpipe vs Svix Ingest vs Hookdeck
All three receive webhooks for you. Each gives you a URL that is always up, verifies events at the door, and absorbs provider retries. The difference is what happens after an event arrives.
One event, three ways to receive it
Push — Svix Ingest and Hookdeck
A gateway forwards events to you
The gateway accepts the event, then pushes it to an HTTP endpoint you run. On the way it can filter, transform, and retry until your endpoint answers. Each event is its own request, so retries can arrive out of order. You still operate a public endpoint, and it must be up when the gateway delivers.
POST https://your-app.com/webhooksPull + stream — dotpipe
An inbox holds events until you read them
dotpipe accepts the event, verifies it, and holds it. Your app or agent connects out when it is ready — poll by cursor, or open a stream that catches up from your position and then delivers new events live. Either way, events arrive in order. Nothing in your stack accepts inbound traffic — and your laptop reads the same way in development, with no tunnel.
GET /events?after=1040Push is the right shape when the consumer must be a public endpoint. Pull fits any reader: an application that wants order and back-pressure, or an agent, cron job, or script with no endpoint at all.
The code you do not write
Most webhook-handling code exists because the sender sets the pace. When your reader sets the pace, that code disappears — and the reader is never the bottleneck under a spike.
Back-pressure is built in
You read at your own pace. A burst waits in the inbox instead of landing on your service all at once. There is no queue to add and no rate limit to tune.
No delivery deadline
A pushed webhook must be answered in seconds, or it is retried. A read has no deadline. Slow work does not cause timeouts or retry storms.
No surprise duplicates
At-least-once push means every handler must deduplicate. With a cursor, redelivery is under your control: advance it when you are done, re-read only when you choose.
Already in order
One ordered stream for each source. No sequence numbers to check and no reorder buffer to build.
The facts, side by side
| dotpipe. | Svix Ingest | Hookdeck | |
|---|---|---|---|
| Model | Pull | Push, with optional pull | Push |
| Streaming | SSE + WebSocket | No | No |
| Ordering | Guaranteed | Best effort | Best effort |
| Rate limiting & back-pressure | Automatic — consumer sets the pace | Preset throttle rate | Preset rate or concurrency cap |
| Cursor tracking | Consumer keeps a cursor | None to track | None to track |
| Retention | 1 hour – 30 days | 30–90 days | 3–30 days |
| Ideal for | Applications and agents | Consumer is a public endpoint | Consumer is a public endpoint |
| dotpipe. | Svix Ingest | Hookdeck | |
|---|---|---|---|
| Model | Pull. An inbox that your app or agent reads — poll by cursor, or open a live catch-up stream. You initiate every connection. | Push. A gateway that forwards events to endpoints you choose, with routing and fanout. A Polling Endpoint can turn delivery into pull. | Push. A gateway that queues events and delivers them to a destination you run. |
| Streaming | SSE streams complete events; WebSocket carries new-event notifications. Both resume from any retained cursor. | No consumer stream. Events arrive as individual HTTP deliveries; a Polling Endpoint is read by repeated polls. | No consumer stream. Events arrive as individual HTTP deliveries to your endpoint. |
| Ordering | Guaranteed. One ordered stream for each source, read from a cursor — polling and streaming both. | Best effort on standard endpoints; retries can reorder events. FIFO endpoints give strict order with one-at-a-time delivery. | Best effort. Arrival order is not guaranteed, and the docs recommend handling out-of-order events. |
| Rate limiting & back-pressure | Back-pressure is built in and automatic: delivery goes only as fast as the consumer reads, and bursts wait in the inbox. Extra rate limiting is a line of code — one operator on the @dotpipe/client stream. | A preset throttle rate (messages per second) smooths peaks, set per application or per endpoint. Throttled messages are delayed, not dropped. | A queue absorbs bursts. A preset max delivery rate or concurrency cap for each destination, set in the dashboard or API. Retuning it during an incident is a config change. |
| Duplicates | Under your control. Advance the cursor when you are done; re-read only when you choose. | At-least-once delivery. Handlers should be idempotent. | At-least-once delivery. The docs recommend idempotent handlers keyed on the event id. |
| Cursor tracking | Yours. The consumer stores its position — one number — and passes it on each read. This is the cost of the pull model; it is also what makes resume and replay work. | Nothing to track. The gateway remembers delivery state for each endpoint. A Polling Endpoint consumer does track an iterator. | Nothing to track. The gateway remembers the delivery state of each event. |
| You must run | Any HTTP client — an agent, a cron job, a script, a Worker. No public endpoint, no inbound traffic. | A public HTTP endpoint that answers each delivery, unless you read from a Polling Endpoint. | A public HTTP endpoint. The CLI forwards events to localhost during development. |
| Signature verification | Yes. | Built in for many providers, including Stripe, GitHub, Shopify, Slack, and HubSpot. | Built in for 160+ source types. Optional HMAC, basic auth, or API key on generic sources. |
| Replay | Re-read any retained event, from any position, as often as you want. | Replay or recover messages from delivery logs. | Retry past deliveries. Bookmark and replay specific requests. |
| Retention | One hour to thirty days, set for each source. | By plan: 30 days on Free, 90 days on Professional. | By plan: 3 days on Developer, 7 on Team, 30 on Growth. |
| Transformations | None, by design. You read exactly what the provider sent. | JavaScript transformations, filtering, and dynamic routing. | Filtering, transformations, and deduplication before delivery. |
Svix Ingest and Hookdeck details come from their public documentation and pricing pages, checked on 23 August 2026. If something here is out of date, tell us and we will correct it.
How to choose
Pick by what your reader looks like, not by feature count. Each of these is the right tool for a different shape of consumer.
Choose Hookdeck
when you run a service with a public endpoint and want a managed pipeline in front of it. It is strong at delivery operations — retries, filtering, transformations, deduplication — with a CLI for local development.
Choose Svix Ingest
when you want webhook receiving and sending on one platform, or you already send with Svix. It verifies many providers out of the box and can transform, filter, and fan out events in JavaScript.
Choose dotpipe
when you would rather read events than host an endpoint for them. Applications get order and back-pressure out of the box. Agents, cron jobs, and scripts read with no endpoint at all — events wait in the inbox while the reader sleeps.
Start here