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
Webhook payloads carry more than event 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’s definition of personal data, most of that qualifies, and some of it is sensitive. We work through which webhook payloads count as personal data field by field.
Your webhook gateway sits in the middle and 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 exported personal data across a border. Chapter V of the GDPR only allows that under specific conditions, and teams often do it without a lawful transfer mechanism and without noticing.
The layer you added to stop losing events has become a data processor handling PII on your behalf. Where it runs, how long it keeps data, and which contract governs it are now your concern as well.
Enterprise buyers come at this from another angle too. Besides the region your gateway runs in, they want to know which addresses it delivers from, because their security team has to allowlist them. A common gap: a team maps its whole data-flow diagram, gets every database and API right, and leaves the webhook gateway off because it felt like plumbing. That gateway 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, “we didn’t check the webhook layer” will not get through 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 lands somewhere else. Read the fine print and you often find the data leaving the EU on a path nobody 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 keeps ingest, storage, workers and backups in the EU, with no exception for any of the four. If one of those legs leaves the region, the “EU-hosted” label describes the sales page rather than the architecture. When you are vetting vendors against these four legs, our eleven-question checklist for EU-hosted Hookdeck alternatives turns them into something you can send to a sales team.
Data residency in the delivery path
The same question applies to the senders at the other end of the pipe. Some teams deliberately pick an EU provider for transactional email or SMS (Sweego, for one, sends from French datacenters), then route its events through a US-hosted inspection tool during development. The recipient addresses leave the EU on a leg nobody wrote down. An EU sender only keeps data in-region if the gateway behind it does too.
Most residency conversations stop at the database. A webhook moves, though. 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, including the time the event spends in transit between attempts.
Consider where the event sits while it waits. In Webhooker, inbound events wait in a durable delivery queue, and 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 in an EU database.
This leg gets overlooked. 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 at the moment the system is under stress.
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. When you ask a provider where the queue runs, also ask where the failed events, the logs and the replay buffer live. Those sit the longest, and auditors look at them first.
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 has to be written down somewhere, since an assumed one gives you nothing to point to.
Retention limits, enforced. GDPR’s storage limitation principle expects you to keep personal data only as long as you 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, the data is deleted rather than soft-deleted or moved to a cold bucket you forgot about.
Right to erasure that actually erases. If someone exercises their right to erasure, the copies sitting in backups and logs are the ones that trip you up. Enforced retention plus real deletion lets you honour an erasure request 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, means a shorter list to reason about and to disclose in your own privacy notice. Read the provider’s notice on how webhook payloads are processed and retained before you commit.
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. Without a DPA, you are running personal data through a vendor with nothing governing how they treat it. Hosting region and DPA availability are where the main gateways differ most, 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 includes a DPA on both paid plans, Pro and Team (see pricing). Some providers reserve the DPA for enterprise contracts, which matters if you are a small team handling EU customer data. The GDPR-compliant webhook relay checklist lists what to ask a vendor for beyond the DPA. If you are weighing a hosted gateway against running one yourself, webhook pricing models compares the costs.
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. Taken together, these events form a record of who paid what, which is data you want kept in-region and tightly held.
The retry queue is the trap here as well. 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 inside the EU. That includes events that fail and are later replayed from the dead-letter queue.
Checklist: is your webhook provider EU-compliant?
Copy this and put it to any provider you are evaluating:
The residency-in-transit and enforced-deletion items are the ones providers most often cannot confirm. When they can’t, look at the delivery path first: the retry queue, the DLQ and the attempt logs are where copies of a payload outlive the request that created them.
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 may look like a plain technical message, but GDPR looks at what it contains. Treat webhook payloads as personal data by default and handle them accordingly.
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, and the EDPB’s recommendations on supplementary transfer measures show how much work that mechanism has to carry.
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, and that gap shows up at audit time.
