Webhooker
EU-hosted webhook infrastructure means every part of the pipeline runs inside the EU: ingest, storage, delivery workers and backups, not just the front door. It matters because webhook payloads routinely carry personal and payment data, and the gateway sees all of it. Keeping that data in-region, with enforced retention and a DPA, is what makes GDPR practical rather than theoretical.
Why webhook data is a compliance problem
A webhook is not metadata. When Stripe fires a charge.succeeded event or your CRM pushes a contact.updated, the payload usually contains names, email addresses, IP addresses, billing details, order contents and internal identifiers. Under GDPR, most of that is personal data, and some of it is sensitive — we work through which webhook payloads actually count as personal data field by field.
Here is the part teams miss. Your webhook gateway is a middleman that sees every byte. It receives the payload, writes it to a queue, holds it while retries happen, and logs the response. If that gateway runs on infrastructure outside the EU, you have just exported personal data across a border, often without a lawful transfer mechanism and usually without noticing.
That is the whole problem in one sentence. The convenience layer you added to stop losing events quietly became a data processor handling PII on your behalf. So where it runs, how long it keeps data, and what contract governs it are now your problem too.
Enterprise buyers ask the same question from the other direction: not only which region your gateway runs in, but which addresses it delivers from, because their security team has to allowlist them. We have watched teams map their whole data-flow diagram, get every database and API right, and leave the webhook gateway off the picture because it felt like plumbing. It is not plumbing. It is a system that stores your customers’ data, sometimes for days, in whatever region its operator picked. When a data protection officer asks where this personal data lives and for how long, a shrug about the webhook layer is not an answer that survives review.
What “EU-hosted” should actually mean
“EU-hosted” gets used loosely. A lot of providers really mean “EU-first”: a primary region in Frankfurt or Dublin, with failover, backups, logging or async processing that quietly lands somewhere else. Read the fine print and the data leaves the EU on the path you never thought to check.
EU-hosted should mean all of it:
- Ingest: the endpoint that receives your webhooks answers from EU infrastructure.
- Storage: payloads and queue state sit in an EU database.
- Delivery workers: the processes that forward events and run retries execute in the EU.
- Backups: snapshots and archives stay in the EU too, because a backup is still a copy of personal data.
Webhooker is EU-only across all four. Not EU-first with exceptions buried in the fine print, but genuinely EU-only webhook ingest, storage, workers and backups. If any one of those legs leaves the region, “EU-hosted” is marketing, not architecture.
Data residency in the delivery path
Most residency conversations stop at the database. But a webhook is not a static record. It moves. It arrives, waits, gets forwarded, maybe fails, waits again, retries, and only then either succeeds or lands in a dead-letter queue. Residency has to hold across that whole lifecycle, not just at rest.
Think about where the event actually sits while it waits. In Webhooker, inbound events land in a deliveries table in PostgreSQL, and workers pull rows with SELECT ... FOR UPDATE SKIP LOCKED. That queue lives in the EU. When a destination is down and the event waits for its next retry with exponential backoff and jitter, it is still sitting in an EU database, not in a buffer somewhere else.
This is the leg people overlook. An event that fails at 2am and retries at 6am spent four hours somewhere. If that somewhere is a queue in another region, your data residency claim has a hole in it exactly when the system is under stress. Residency you can defend covers the waiting, not only the writing.
The dead-letter queue makes this sharper. When a destination stays down past its retry budget, the event does not vanish. It lands in a DLQ and waits for a human to resend or bulk-replay it, which can be hours or days. Every one of those events is personal data at rest in your gateway, and every stored attempt log and response body is another copy. So ask a provider not just where the queue runs, but where the failures, the logs and the replay buffer live. Those are the parts that sit longest and get audited hardest.
GDPR essentials for a webhook layer
You do not need a general GDPR lecture. You need the parts that touch a webhook pipeline specifically, and there are four.
Lawful basis and roles. You are the controller for the data in your webhooks. Your gateway is a processor acting on your instructions. That relationship needs to be real and documented, not assumed.
Retention limits, enforced. GDPR expects you to keep personal data only as long as you actually need it, so a gateway that stores payloads and logs forever is a growing liability. Webhooker enforces retention by plan, 14 days on Free, 30 on Pro, 90 on Team, and when the window passes, deleted means deleted. Not soft-deleted, not archived to a cold bucket you forgot about.
Right to erasure that actually erases. If someone exercises their right to be forgotten, the copies hiding in backups and logs are the ones that trip you up. Enforced retention plus real deletion is what makes an erasure request something you can honour end to end. On some platforms erasure arrives as a webhook of its own — Shopify apps must handle mandatory data-request and redaction topics to stay listed.
Sub-processors. Every service your gateway relies on to handle data is a sub-processor you should be able to name. Fewer of them, all in-region, is a shorter list to reason about and a shorter list to disclose in your own privacy notice. It is worth reading how webhook payloads are processed and retained before you commit to anyone.
DPA: the paperwork you need
A Data Processing Agreement is the contract that makes the controller-processor relationship legally real. Under GDPR Article 28, if a processor handles personal data for you, you are supposed to have one. No DPA, and you are running personal data through a vendor with nothing governing how they treat it. Hosting region and DPA availability are exactly where the main gateways diverge, which is why we compare Webhooker, Svix and Hookdeck on both.
A useful DPA for a webhook provider should cover:
- The scope and purpose of processing, and the categories of data involved.
- Instructions: the processor acts only on yours.
- Confidentiality and security commitments.
- Sub-processor terms, and how you get told when they change.
- Deletion or return of data when the contract ends.
- Assistance with data-subject requests and breach notification.
Webhooker offers a DPA on every paid plan, so you get it on plans with a DPA on every paid tier rather than only at enterprise. If you are weighing that against running the gateway yourself, we set the models against each other in webhook pricing models. When a provider treats the DPA as an enterprise-only add-on, that tells you where compliance sits on their priority list.
Payment webhooks (Stripe et al.) inside the EU
Payment webhooks are the sharp end of this. A Stripe payment_intent.succeeded or invoice.paid event carries the amount, currency, customer references, partial card metadata and billing context. It is a running record of who paid what, and it is exactly the kind of data you want kept in-region and tightly held.
The failure trap is the retry queue again. Payment events are the ones you most want delivered reliably, which makes them the ones most likely to sit in a queue through several retry attempts when your billing service hiccups. If that queue is out of region, your most sensitive event trail is the one spending the most time outside the EU.
With Webhooker, a Stripe event hits an EU ingest URL, gets its signature verified with HMAC-SHA256 before the payload is accepted, then waits, retries and gets logged entirely inside the EU. The payment trail stays where you can account for it: through delivery, through failure, and through replay from the dead-letter queue.
Checklist: is your webhook provider EU-compliant?
Copy this and put it to any provider you are evaluating:
If a provider cannot say yes to the residency-in-transit and enforced-deletion items, the gaps are usually in the delivery path, the part that is hardest to see and easiest to get wrong.
Frequently asked questions
Are webhooks personal data?
Usually, yes. Webhook payloads regularly include names, email addresses, IP addresses, order details and payment references, all personal data under GDPR, some of it sensitive. The event itself may look like a plain technical message, but its contents are what count. Treat webhook payloads as personal data by default and handle them accordingly, rather than assuming a system event is somehow exempt.
Is US-hosted with an EU region enough?
Often not. A US-based provider offering an EU region still routes control-plane traffic, logging, backups or async processing outside the EU in plenty of setups, and the parent company may be subject to non-EU data laws. “EU region available” is not the same as EU-only. If personal data can leave the region on any leg of the path, you are relying on a transfer mechanism rather than true residency.
Do I need a DPA?
If a webhook provider processes personal data on your behalf, GDPR Article 28 expects a Data Processing Agreement between you, and for nearly every real webhook pipeline that means yes. The DPA sets out what the processor may do, how it secures data, which sub-processors it uses, and how deletion and data-subject requests get handled. Without one, you are the controller with no contract governing your processor, a gap that helps no one at audit time.
Ready to keep your event data in-region from the first request? You can start receiving webhooks in the EU on the free plan and move up to a DPA-backed paid tier when you need it.