GDPR-Compliant Webhook Relay: A Buyer's Checklist

A GDPR-compliant webhook relay is one that lets you, the controller, meet your own obligations while it handles payloads as your processor under Article 28. On data residency, that means a processing region that covers ingest, storage, delivery workers and backups, a named sub-processor list, and a DPA on the plan you would actually buy. The relay should also enforce retention with real deletion, encrypt payloads in transit and at rest, record who reads them, and name a transfer mechanism if any leg leaves the EU. No product is “GDPR certified” in a way that settles this. You have to check features and contracts one by one.

We build Webhooker, so read this as a vendor’s page. Every fact about another vendor links to that vendor’s own page, checked on 21 September 2026. We are not lawyers, nothing here is legal advice, and your DPO has the last word.

This post is the procurement checklist. For background, see which webhook payloads count as personal data and why every leg of the pipeline has to sit in the EU.

What does “GDPR compliant” mean for a webhook relay?

Less than the badge suggests. The GDPR puts obligations on controllers and processors, not on products. When a relay receives, stores and forwards a Stripe or Shopify event on your behalf, you are the controller and the relay is a processor. Article 28 says you may only use processors that provide “sufficient guarantees”, bound by a contract.

Vendor pages often list “GDPR” in the same row as SOC 2 and HIPAA, as if the three were the same kind of thing. SOC 2 and ISO 27001 are security audits carried out by an outside firm. They are useful evidence for Article 32, but they say nothing about where data is processed or how long it is kept. The GDPR has certification mechanisms in Article 42, but Article 42(4) states that a certification does not reduce the responsibility of the controller or the processor. A “GDPR compliant” label is the vendor’s own claim, and your review starts there.

Which data residency features should a webhook system offer?

Ask for the processing region of each leg. A webhook arrives at an ingest endpoint, is written to a database, waits in a queue, is forwarded by a worker, may fail and wait again, and ends up in a backup. A webhook gateway that names only its “primary region” has answered one question out of five.

The five are ingest, storage, delivery workers, backups, and the tooling around them. Tooling is where it usually leaks. A stack trace in an error tracker with the request body in it is a copy of the payload in another vendor’s cloud.

Two answers are acceptable. Either there is one region and no setting, or you select a region and get a written statement of which legs it covers. Look hardest at the retry queue and the dead-letter queue, where failed events sit the longest.

What should the DPA and the sub-processor list contain?

Article 28(3) lists what the contract must cover: processing only on your documented instructions, confidentiality, security measures, sub-processor terms, assistance with data subject requests in point (e), deletion or return of data at the end of the contract in point (g), and audits in point (h).

Reading the text is not enough, though.

Start with which plan includes the DPA. Some vendors publish one for every customer, others attach it to a paid tier. If the DPA starts at a plan you will not buy, you do not have one.

Then find out how sub-processor changes reach you. Where you have given general authorisation, Article 28(2) requires the processor to tell you about intended changes so you can object. Look for the notice mechanism and the objection window.

Last, check which sub-processors see payloads. A billing provider that sees your invoice address is a different risk from a database host that stores every event body, and a good list tells them apart.

How should a relay handle retention, deletion and erasure requests?

Storage limitation in Article 5(1)(e) applies to the relay’s event log as much as to your user table. A relay keeps the payload, the headers, and every delivery attempt with its response body. That history makes replay possible. It is also a second copy of your customers’ data.

Ask for a retention window the system enforces, stated per plan, and for deletion that reaches every copy: payload, attempt log, dead-letter queue and backups. You also need a route for Article 17 erasure requests. They come to you, and the relay has to let you act on them. Per-event deletion is the ideal. The realistic fallback is a short window, so copies expire on their own, plus a named contact.

Watch the wording. “We reserve the right to delete data older than your retention period” is a right the vendor keeps. It does not commit the vendor to deleting anything on schedule.

Which security controls does Article 32 point to?

Article 32 asks for measures “appropriate to the risk”. For a relay, that comes down to encryption, access control, an audit trail, the handling of requests that fail verification, and log redaction.

Encryption should cover data in transit and at rest. That means TLS on ingest and on delivery with a stated minimum version, and encryption at rest for the database and the backups with the algorithm named.

For access control, look for roles, MFA, and SSO if your policy requires it. Then ask who at the vendor can open a payload, and under which procedure.

Two different logs get called an audit trail. One records what happened to each event: received, verified, delivered, failed, replayed. The other records what people did in the account, and is often reserved for higher plans. Ask about both.

A relay that verifies signatures has to decide what to do with a request that fails. Storing it helps an investigation, but it can still carry personal data. It should never reach your destinations, and it should expire under the same retention rules as everything else.

Payloads also leak into application logs, error reports, alert emails and support tickets. Ask whether the vendor keeps payload bodies out of its operational logs. Transformations that strip fields before delivery are no answer here, because they limit what downstream systems receive and leave what the relay stores untouched.

What changes if the relay is hosted in the US?

Then every payload is an international transfer under Chapter V, Articles 44 to 49, and you need a transfer mechanism you can name. There are two in practice. One is the EU-US Data Privacy Framework, an adequacy decision from July 2023 that covers only US companies that have self-certified, so look the vendor up on the official DPF list. The other is the Standard Contractual Clauses under Article 46, which come with a transfer impact assessment on your side.

The General Court upheld the DPF in September 2025, and an appeal is pending before the Court of Justice. A DPA that names SCCs as a fallback is the careful version. Check the age of the document too: one that still refers to the Privacy Shield, struck down by the Court of Justice in 2020, tells you when it was last reviewed.

US hosting is allowed. It does put work on your desk, because the transfer has to go into your records of processing and your privacy notice.

The checklist: what should you demand from a webhook relay?

Table: twelve things to ask a webhook relay before you route personal data through it, the GDPR provision behind each, and what a good answer looks like.

How do current webhook relays and gateways measure up?

Each paragraph covers only what the vendor publishes, as of 21 September 2026. Anything we could not verify is left out, which does not mean the vendor fails it.

Webhook Relay

Webhook Relay forwards webhooks to public URLs, private servers and localhost. Its GDPR page says forwarded webhooks are recorded with body, headers and destination, kept as long as the plan allows and then deleted automatically. It names Google Cloud as the main infrastructure provider, is dated 1 June 2018, and does not mention a DPA or a transfer mechanism, so ask for both. The default tunnel region is Belgium, with a note that the country can change without notice. The pricing page says webhook data is encrypted in transit and at rest, and lists SAML SSO and a SOC 2 report under Enterprise.

Hookdeck Event Gateway

Hookdeck Event Gateway fails item 1 for EU-only buyers by its own account: “Event Gateway is currently hosted in the US only”. The sub-processor list, effective 7 May 2026, names fifteen vendors with their roles. The DPA promises notice before a new sub-processor is authorised, a ten-day objection window, and deletion or return at the end of the service. Its transfer clause still refers to the Privacy Shield, with the 2021 SCCs as the fallback. The pricing page sets retention at 3, 7 and 30 days by plan and puts SSO and a read-only role on Growth, from $499 a month. Webhooker vs Hookdeck has the rest.

Svix Ingest

Svix Ingest comes from a vendor that lets you pick a region. The pricing page lists isolated regions for data residency on every plan, with 30-day payload retention on Free and 90 days on Professional. The EEA DPA and the SOC 2 Type II report start at Professional, from $490 a month, and audit logs are Enterprise only. The security page states 256-bit AES at rest, TLS 1.2 or 1.3 in transit and encrypted backups. We did not find a public sub-processor list, so ask for one.

Convoy

Convoy receives and sends. Its DPA, last updated 19 March 2025, says it runs separate EU and US environments, processes EU personal data within the EU, and deletes or returns personal data within 60 days of termination. Its free self-hosted edition removes the processor and hands you the whole checklist, which is the trade-off covered in build vs buy webhook infrastructure.

Hook0

Hook0 sends webhooks and does not receive them, so it is not a relay. It is here because its paperwork is a useful benchmark. Its DPA, updated 27 June 2026, warrants that webhook payloads, the database and application backups are located in France or the EEA. It discloses one non-EU leg, Cloudflare for CDN and DDoS protection, covered by SCCs and a transfer impact assessment. Retention is 7, 14 or 30 days by plan. One clause to note: if you ask for help meeting your own obligations, Hook0 first quotes you the cost.

Webhooker

Webhooker only receives. Ingest, storage and delivery workers run on Hetzner servers in Germany, backups stay in the EU, and there is no region to select. The privacy notice names the sub-processors, says webhook payloads are processed and stored only in the EU, and states TLS 1.2 or higher in transit and AES-256 at rest. Retention is enforced per plan (14 days on Free, 30 on Pro, 90 on Team), and at expiry the payload and its delivery history are deleted. Signatures are verified per source. A request that fails gets a 401, is stored for the audit trail, is never delivered, and expires with everything else. The DPA comes with both paid plans, from €29 a month on pricing, and not with Free. The gaps: there is no SSO, and the dashboard has no per-event delete or search-by-person tool yet, so erasure relies on the retention window, on deleting a source or the account, or on a written request. If you need a third-party audit report such as SOC 2, ask us before you shortlist.

For more, see Webhooker vs Svix vs Hookdeck and the Hookdeck alternatives guide.

You can test two of the checklist items yourself instead of taking a vendor’s word for them. Send a test event with a dummy email address and see whether it is gone when the retention window ends. Send a request with a bad signature and confirm that it never reaches your destination. To try both on Webhooker, create a free source. Its ingest URL has the form https://app.webhooker.eu/in/<token>.

Frequently asked questions