Webhooker
If you are shopping for a Hookdeck alternative, the useful question is not which brand to swap in but which category of tool you actually need: an EU-hosted inbound gateway, an outbound webhooks-as-a-service platform, a queue you run yourself, or a general automation platform. Data residency, the billing unit and inbound-versus-outbound focus decide it far more often than any feature checklist does.
This page is written by the team behind one of those alternatives, so weigh it accordingly. It makes no claims about anyone else’s prices, limits or regions, because those change and a competitor’s blog is the worst place to read about them.
Why teams look for an alternative
There are four real reasons. Everything else turns out to be a variation on one of them.
Data residency and GDPR paperwork. A gateway is not a router that forwards bytes and forgets them. It stores payloads while they wait, keeps response bodies and per-attempt logs, and parks failed deliveries in a dead-letter queue for hours or days. That data carries names, emails and order contents. When your DPO asks where it lives, “the provider has an EU region” is half an answer; the other half is where the workers, the retry buffer and the backups run.
Pricing model fit. Gateways bill on different units: inbound events, delivery attempts, destinations, connections, or some blend. The unit matters more than the headline price. If you fan one order event out to three destinations and get billed three times, your cost scales with your architecture rather than your traffic. We wrote separately on how to compare pricing models fairly, because the comparison is hard to do by eye.
Inbound versus outbound focus. “Webhook infrastructure” covers two problems that share a word. Receiving events from Stripe, GitHub and your PSP is one. Sending events to your own customers, with endpoint management and subscriber-facing tooling, is the other. A tool built for the second is not automatically good at the first.
Surface area you do not need. Some teams have exactly one problem — Stripe events must never be lost — and end up on a platform built for a much broader remit. That is not a criticism of the platform. It is a mismatch, and mismatches cost money and attention.
What Hookdeck is good at
Hookdeck is an established, general-purpose event gateway. At the time of writing (August 2026) it positions itself around both receiving and sending event traffic, with a developer-oriented workflow, and it has been in this space long enough to have a mature product behind that positioning.
We are not going to summarise its feature list or quote its prices here. Those are theirs to state, they move, and a page like this one is the wrong source. Read their own documentation and pricing page and take the answers from there.
What we will say is this: if you are looking around because of a vague sense that something better exists, rather than a constraint you can name in one sentence, switching gateways is a lateral move. You pay a migration, rebuild dashboards and runbooks, and land on a different set of trade-offs. The four reasons above are worth acting on. General dissatisfaction is not.
The criteria that actually decide it
Feature grids are easy to write and mostly useless, because every gateway ticks “retries” and “replay”. These are the questions that separate them in practice.
Table: the questions that decide a webhook gateway choice and why each one matters. Every answer is time-sensitive — check them against each vendor’s current documentation rather than an article, including this one, dated August 2026.
| Criterion | What to ask | Why it decides |
|---|---|---|
| Hosting region | Where do ingest, storage, workers and backups each run? | One leg outside the region breaks the residency claim |
| Sub-processors | Who else touches the payload — hosting, logging, monitoring? | Your DPO needs the full list, not the front door |
| DPA | Available on the plan you would actually buy? | Otherwise you cannot document the controller-processor split |
| Direction | Built for receiving, sending, or both? | The wrong direction means fighting the tool daily |
| Verification | Which schemes, and checked before acceptance? | Verifying after storage means storing untrusted data |
| Failure handling | Backoff, circuit breaker, DLQ, bulk replay, per-attempt history | This is the reason a gateway exists |
| Transformations | Reshape payloads and inject headers per destination? | Otherwise adapter code moves back into your app |
| Billing unit | Event, attempt, destination or connection? Fan-out billed? | Decides whether cost tracks traffic or architecture |
| Overage | At 101% of quota: a bill, a throttle, or a warning? | Decides whether a spike is an incident or an invoice |
| Retention | How long are payloads and logs kept, and can you shorten it? | A debugging tool and a compliance liability at once |
| Ordering | Per-destination FIFO available, and on which plan? | Ordering costs head-of-line blocking, so global-only is the wrong shape |
Answer those eleven for any candidate and the shortlist writes itself. Note how few are features in the marketing sense.
Category 1: EU-hosted inbound gateways
This category exists because of the first reason on the list. A gateway here is built to receive events, and it can name every place your data touches inside the EU. Expect a per-source ingest URL, verification before acceptance, a durable queue, retries with a circuit breaker, a dead-letter queue with replay, delivery history you can hand to an auditor, and a DPA without a sales call. Do not expect much surface for the outbound case; these tools are deliberately narrower.
Webhooker sits here, with EU-only ingest, storage, workers and backups and retention limits enforced per plan. Each source gets its own ingest URL at https://webhooker.eu/in/{token}, which returns 200 OK in single-digit milliseconds — our p99 target is under 10 ms server-side — while delivery runs out of band in workers. Signatures are verified per source with HMAC-SHA256 or SHA1 before the payload is accepted. Failed deliveries retry with exponential backoff and conditional rules by status code, a per-destination circuit breaker isolates an endpoint that is clearly down, and anything that exhausts its attempts lands in a dead-letter queue with one-click and bulk replay plus per-attempt history. Delivery is at-least-once, so your consumers still need to be idempotent. No gateway removes that obligation.
On billing, one event means one inbound webhook received. Fan-out is not billed, so routing an order event to your database, your analytics and a Slack alert costs the same as routing it to one place. There is no overage billing either: usage up to 120% of the monthly quota is free. These are per-event plans with a DPA on every paid tier, starting with a free tier of 10,000 events a month across 3 sources. Ordered delivery and a static outbound IP are Team-plan only, so check those early if you need them.
If your evaluation is down to specific products rather than categories, the head-to-head comparison of the three gateways goes into that detail. Otherwise, try an EU-hosted gateway free and point one non-critical source at it before deciding anything.
Category 2: outbound webhooks-as-a-service
The second category solves the mirror problem. These platforms exist so your product can send webhooks to your customers: subscriber and endpoint management, signing keys your users can rotate, a portal where their developers inspect deliveries, per-subscriber retry policies.
If that is your problem, this category is the right answer and an inbound gateway is not. The trouble starts when teams pick an outbound platform for an inbound job because both are filed under “webhooks”. Receiving is a different shape: you do not control the sender, you cannot ask Stripe to change its retry policy, you verify a signature scheme somebody else designed, and your recovery tool is replay rather than resubscribe. A data model that starts from “your customer’s endpoint” fights you on every one of those.
The test is one question: who owns the endpoint you are managing? If it belongs to your customer, you want this category. If it belongs to a provider you receive from, you do not.
Category 3: DIY on a queue
You can build this. A route that accepts a POST, verifies an HMAC, writes to a deliveries table in PostgreSQL, and a worker pool that claims rows with SELECT ... FOR UPDATE SKIP LOCKED and forwards them with backoff. The first version is an afternoon of work, and for one low-stakes source it is the correct amount of engineering.
The cost is not in the build. It is in what arrives afterwards: per-provider verification schemes that change, a circuit breaker so one dead destination cannot starve your worker pool, a replay UI somebody other than you can operate, per-attempt logs with response bodies, alerting, retention enforcement, and the on-call rotation that owns all of it at 2am. That work never finishes, and it competes with your product roadmap.
Build when webhook handling is close enough to your core product that owning it is an advantage, when compliance requires the data never to leave infrastructure you control, or when your volume makes any per-event price absurd. Otherwise you are funding a small permanent team to maintain a commodity.
Category 4: iPaaS and automation platforms
Zapier-style automation platforms will catch a webhook and do something with it, and at low volume with low stakes that is a reasonable answer. A form submission that posts to a spreadsheet does not need a gateway.
They weaken where a gateway is meant to be strong. Signature verification is often left to you or skipped, which means an endpoint anyone can POST to. Replay usually means re-running an automation rather than redelivering the stored event with its original payload. Delivery history is a run log with short retention, not a per-attempt record with response bodies. And per-task pricing gets expensive fast, because webhooks arrive in bursts.
Use them as glue between SaaS tools. Do not use them as the front door for payment events.
A decision guide
Table: which category fits which constraint. Read the left column as the sentence you would use to describe your own situation.
| If this describes you | Look at |
|---|---|
| Personal or payment data in payloads, EU residency required, a DPO asking specifics | EU-hosted inbound gateway |
| Several providers to receive from; you need verification, replay and history | EU-hosted inbound gateway |
| Your product sends webhooks to your own customers | Outbound webhooks-as-a-service |
| Webhook handling is core to your product, or volume makes per-event pricing absurd | DIY on a queue |
| One low-stakes source, no personal data, no money involved | A plain endpoint or an automation platform |
| It works, region is not a constraint, and you cannot name a specific gap | Stay where you are |
That last row is not a courtesy. If Hookdeck is serving you, your residency requirements are satisfied, and the billing unit matches how your traffic behaves, then migrating buys you a project and no outcome. Repointing every provider, running both paths in parallel while you verify, rebuilding alerting, retraining whoever is on call: spend that on a constraint you can name, not on a hunch. For teams who can name one — usually residency, sometimes the billing unit — the move is worth making, and the way to de-risk it is to run a single non-critical source through the new gateway for a couple of weeks first.
Frequently asked questions
Is there a European alternative to Hookdeck?
Yes. EU-hosted inbound webhook gateways exist as a category, and Webhooker is one of them. The distinction worth checking is between EU-hosted and EU-only: many providers offer an EU region for the primary database while logging, monitoring, async processing or backups run elsewhere. Ask where ingest, storage, delivery workers and backups each run, then ask for the sub-processor list. Webhooker keeps all four in the EU, enforces retention limits per plan, and offers a DPA on every paid plan. Your DPO should still review it, since you remain the controller.
Can I migrate without changing provider URLs?
No, and be suspicious of anyone who says otherwise. A gateway owns the ingest URL, so moving means updating the endpoint configured at every provider — Stripe, GitHub, your PSP, each separately. There is no way around that step. What makes it low-risk is that most providers allow more than one endpoint per event type, so you can register the new gateway alongside the old one, compare what arrives on both for a week or two, and only then remove the original. Plan for a parallel period rather than a cutover.
What should I ask a provider about data residency?
Four questions, in this order. Where does ingest terminate? Where do payloads and queue state sit at rest, including the dead-letter queue? Where do the delivery workers that run retries execute? Where do backups and archives live? Then ask for the sub-processor list, because hosting, logging and monitoring vendors all see data too. Finally ask whether a DPA is available on the plan you would actually buy, not just on enterprise. The GDPR text defines the controller-processor split these answers have to satisfy; check the specifics with your DPO.