Are Webhooks Personal Data? GDPR for Payloads with PII

Usually, yes. If a webhook payload carries an email address, a name, a postal address, a customer ID that can be traced back to a person, or an IP address, it is commonly treated as personal data under the GDPR, which defines personal data in Article 4(1) as any information relating to an identified or identifiable natural person. A typical checkout, subscription or support event contains at least one of those, which makes your webhook layer a place where personal data is received, stored and forwarded.

Few webhook layers are designed with that in mind. They start as plumbing: someone adds an endpoint, someone else adds logging so the endpoint can be debugged, and a year later there is a table of two million JSON blobs nobody has mapped in a record of processing activities. We run webhook infrastructure and are not lawyers, so use what follows to ask better questions and check the answers with your DPO.

What a typical webhook payload actually holds

Open any payload from a payments provider, an e-commerce platform or a helpdesk and you find the same shape: an event type, a timestamp, an object ID, and a nested object describing something that happened to a customer. The customer is the problem. Even an event that looks anonymous, carrying nothing but IDs, is still personal data, because you can join that ID to a person in your own database. If you couldn’t, the event would be useless to you.

Table: fields that turn up in ordinary webhook payloads, and why each is commonly treated as personal data.

The table also hides duplication: the same identifier often appears in more than one field. Delivery events from email providers commonly repeat the recipient address inside a raw SMTP log string as well as in the dedicated field (Sweego’s details field does this). A redaction rule written against the obvious field leaves a second copy behind in free text.

Asking “does this event type contain PII?” once does not settle it. An event type that carries none today will start to when a provider adds a field to their schema. Assume the stream carries personal data and design the layer for that.

Payment data raises the stakes

Card numbers rarely appear in webhook payloads, because payment providers tokenise them so they do not travel. What does appear is payment metadata: last four digits, card brand, issuing country, billing address, amount, and the merchant’s description of what was bought.

None of that is a special category by itself, but it is financial data about an identified person, and the description field can make it worse. “Monthly donation: political party X”, or an order line from a pharmacy, can reveal political opinions or health information. Those are special categories under Article 9, with a stricter regime attached. Nobody designed the webhook to carry them; they arrived because a free-text field was passed through. If your product touches health, religion or politics at all, that passthrough deserves its own conversation with your DPO.

Controller and processor: which one are you?

You are the controller. You chose to receive these events, you decide what happens to them, and you hold the relationship with the data subject. That does not change because the data arrives over HTTP from someone else’s server.

A webhook gateway is a processor, in the sense the EDPB guidelines on controller and processor describe. It receives, verifies, stores and forwards payloads on your instructions and should be doing nothing else with them. Article 28 expects that relationship to be written down, which is what a Data Processing Agreement is for. Webhooker includes a DPA on the paid plans, Pro and Team (see pricing).

The split has consequences for day-to-day work. If you run the receiver yourself, the whole obligation is yours; the trade-off is laid out in build vs buy for webhook infrastructure. You define the purpose and choose the retention window, and the processor enforces that window instead of deciding what is reasonable for your business. Data-subject requests come to you, and the gateway has to let you act on them in its own storage. The processor names its sub-processors and secures the data, including where the bytes physically sit, so residency is part of the processor’s side of the deal. Webhooker runs ingest, storage, workers and backups in the EU; what we process, and for how long, is described in how webhook payloads are processed and retained.

The obligations that touch a webhook layer

Most of the GDPR applies to events the same way it applies to any other data. Five obligations look different on a webhook layer: lawful basis, data minimisation, storage limitation, security of processing and sub-processor transparency.

1. Lawful basis. Under Article 6, you need one for receiving and storing the payload, in addition to the one covering the underlying business relationship. In most B2B setups it rests on contract performance or legitimate interests, but the assessment is yours to make and document.
2. Data minimisation. Article 5(1)(c) limits data to what is necessary, yet providers send their full event schema even when you need three fields. Payload transformation at the gateway (dropping or rewriting fields before delivery) narrows what reaches downstream systems.
3. Storage limitation. Covered below, because it is where webhook layers usually fail.
4. Security of processing. Article 32 asks for measures appropriate to the risk: TLS, access control on the event log, residency, and signature verification on every source. Don’t switch verification off to debug, even briefly.
5. Sub-processor transparency. Your privacy notice describes who handles personal data on your behalf. Your gateway belongs on that list, and so does anything it depends on.

Retention: the part most teams get wrong

Storage limitation, in Article 5(1)(e), means keeping personal data only as long as you need it for the purpose you collected it for. Everyone accepts that for their user table. Almost nobody applies it to event logs.

A webhook layer doing its job well stores a durable copy of every payload, plus a full per-attempt delivery history with request and response bodies. That history is what makes replay out of a dead letter queue and debugging possible. It is also a second, parallel copy of the same personal data, in a table nobody reviews, growing daily, and usually excluded from the deletion logic that runs against your primary database.

“We keep logs forever, disk is cheap” is a storage-limitation problem with an engineering excuse attached. Disk is cheap. A five-year archive of every customer email that passed through a checkout event gets expensive once someone asks you to account for it.

The fix is a retention window enforced by the system rather than promised in a document. Webhooker enforces retention by plan (14 days on Free, 30 on Pro, 90 on Team), and when the window passes, the data is deleted. Pick the shortest window that still lets you investigate an incident. If nobody on your team has ever looked at an event older than a week, a 90-day window adds liability without adding anything you use.

What deletion has to mean

Deletion is only real if it reaches every copy. Ask any provider, us included, where the copies are:

• The stored payload. The event body as received.
• The delivery history. Every attempt, with the request you sent and the response body you got back, which often echoes the same personal data.
• The dead-letter queue. Failed deliveries parked deliberately for replay, and therefore exempt from cleanup unless someone thought about it.
• Anything derived. Search indexes, filters, metric labels built from payload fields.

A provider that deletes the payload but keeps the attempt log has not deleted anything meaningful. When we say retention is enforced, that includes the delivery history, because a destination’s response body is as much personal data as the payload that triggered it.

Erasure requests raise the same question in a form someone will check. When a data subject asks to be forgotten under Article 17, the copies that trip teams up are the replay queue and the debug log. With a short, enforced window, most of those copies expire on their own. Backups need a separate answer: get in writing what a provider holds in them, and for how long.

Some platforms make the obligation explicit. Shopify requires apps to handle mandatory data-request and redaction webhooks, so erasure arrives as an inbound event you have to process. See how Shopify’s mandatory redaction webhooks work for the topics and the verification involved.

A checklist for your webhook layer

[ ] Do you know which event types carry personal data, free text included?
[ ] Is there a documented lawful basis for storing payloads, not just for the service?
[ ] Do you strip or transform fields you do not need before delivery?
[ ] Is there a retention window on stored payloads, enforced by the system?
[ ] Does that window also cover delivery history and the dead-letter queue?
[ ] Can you honour an erasure request across every copy, including replay data?
[ ] Is a DPA in place, and can the provider name its sub-processors?
[ ] Do you know where ingest, storage, workers and backups physically run?
[ ] Is inbound signature verification on for every source?

Most teams that go through it find two or three items nobody has considered, rather than ten that are broken. That list audits your own pipeline; for vetting a vendor, use the GDPR-compliant webhook relay checklist. That is normal for a layer built under time pressure to solve a delivery problem, with the data-protection questions arriving afterwards. To settle an argument internally, the GDPR text on EUR-Lex beats any summary of it, and the European Data Protection Board publishes the guidelines regulators use.

To see what an enforced window looks like, create an EU ingest URL on the Free plan, send it a few test events carrying a dummy email address, and check that the payload and its attempt log are gone once the 14-day window has passed.

Frequently asked questions