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. 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.

That is an uncomfortable realisation, because the webhook layer is rarely designed with it in mind. It starts 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. What follows is written by people who run webhook infrastructure, not lawyers — use it 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 — nothing but IDs — is personal data in practice, because you can join that ID to a person in your own database. Otherwise 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.

You cannot settle this by asking “does this event type contain PII?” once. The types that do not 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 — payment providers tokenise them precisely 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 is where it gets interesting. “Monthly donation — political party X”, or an order line from a pharmacy, can reveal political opinions or health information, and those are special categories under Article 9 with a stricter regime attached. Nobody designed the webhook to carry that; it 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. 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 offers a DPA on every paid plan rather than as an enterprise upsell, because a processor without a contract is a gap in your paperwork, not a feature tier.

The split has practical consequences. If you run the receiver yourself the whole obligation is yours; the trade is laid out in build vs buy for webhook infrastructure. You define the purpose and choose the retention window; the processor enforces it rather than deciding what is reasonable for your business. Data-subject requests come to you, and the gateway’s job is 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 — which is why residency belongs here. Webhooker runs EU-only ingest, storage, workers and backups; what we process, and for how long, is in how webhook payloads are processed and retained.

The obligations that touch a webhook layer

Most of the GDPR does not change shape when the data is an event. Five parts show up differently.

1. Lawful basis. You need one for receiving and storing the payload, not only for 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. Providers send their full event schema, not the three fields you need. 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. TLS, access control on the event log, residency, and signature verification on every source — never switch that off to debug, not even temporarily.
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 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 wearing an engineering justification. Disk is cheap. A five-year archive of every customer email that passed through a checkout event is not, 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 goes. Pick the shortest window that still lets you investigate a real incident. If nobody on your team has ever looked at an event older than a week, a 90-day window is not caution, it is liability you chose to keep.

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 reflects the same personal data straight back at you.
• 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 are the visible version of the same question. When a data subject asks to be forgotten, the copies that trip teams up are the replay queue and the debug log. A short, enforced window makes most of that solve itself over time. Backups are a separate conversation: what a provider holds in them, and for how long, is something to get in writing rather than assume.

Some platforms make the obligation explicit. Shopify requires apps to handle mandatory data-request and redaction webhooks, turning erasure into an inbound event you process — see Shopify’s mandatory redaction webhooks in practice. It is where compliance stops being a policy and becomes an endpoint.

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?

Run it honestly and you will usually find two or three items nobody has considered rather than ten that are broken. That is normal: the layer got built under time pressure to solve a delivery problem, and the data-protection questions arrived 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.

If you want the layer itself to help rather than hinder, you can receive webhooks inside the EU on the free plan, with enforced retention from the first event.

Frequently asked questions