Data Requests

Someone you emailed writes and asks you to delete what you hold on them. Under the NDPA and the GDPR that request is yours to answer, not Quolle's — you decide who you mail, so you are the controller and Quolle is your processor. This page covers how to carry it out and what is left afterwards.

Running an erasure

In the dashboard, go to Settings → Danger Zone → Privacy requests, enter the address from their request, and confirm. The erasure applies to your account only: if the same person is also a contact of another Quolle customer, that is a separate relationship and is untouched.

There is no undo. Everything listed below is removed the moment you confirm, and Quolle keeps no shadow copy to restore from — that is the point of the feature. Satisfy yourself the request is genuine before you run it.

What is removed

Data	What happens
Contact record	Deleted — name, phone, custom fields and all.
Messages you sent them	Kept as a dated record, with the address, subject, template variables and metadata stripped. See below.
Open events	Deleted. These carry the recipient's IP address and user agent, which is the most identifying data in the record. The count of opens stays on the message.
Campaign recipient rows	Deleted, across every campaign of yours they appeared in.
Flipbook reading records	Deleted in full — the per-page timings, how far they read, which links inside the document they followed, whether they downloaded a copy, and the link itself, which stops working. Not redacted like a send: nobody needs an anonymous trace of who read page four.
Inbound mail from them	Deleted, including the stored body.

Why sends are stripped rather than deleted

Deleting the message rows outright would satisfy the request and destroy your own record at the same time. Asked six months later whether you emailed somebody on the third — by that same person, most likely, or by a regulator acting on their complaint — you would have nothing to answer with.

So the row survives with everything identifying removed. What remains is that a message went out on a date, from a sending domain, and was delivered or bounced. The address and subject read [erased]. With the identifiers gone it is no longer personal data, so the erasure stands and your evidence stands with it.

A message addressed to several people is treated differently: only their address is taken out of the recipient list. The subject and variables belong to the other recipients too, and erasing one person must not quietly erase the rest.

What is deliberately kept

The suppression record — a single entry holding the address and the reason it was suppressed. If somebody unsubscribed or hard-bounced, they are on that list precisely because they should not be contacted. Deleting it clears the way to mail them again the moment the address is re-imported from a CSV or a signup form, which undoes their wishes rather than honouring them. Both the NDPA and the GDPR treat a minimal suppression record as the legitimate way to keep honouring an objection.

If you want that entry gone too, ask support and we will remove it — but understand that the person becomes contactable again, and any future mail to them is on you.

Confirming it is done

The form reports what it changed, so you can tell the person specifically rather than just assuring them. A typical result:

{
  "email": "ada@example.com",
  "contacts": 1,
  "emailsRedacted": 214,
  "emailsPartlyRedacted": 3,
  "openEventsDeleted": 96,
  "broadcastRecipients": 0,
  "campaignRecipients": 11,
  "flipbookReadsDeleted": 2,
  "inbound": 2,
  "suppressionKept": true
}

Zeroes are normal. Somebody who only ever received transactional mail has no campaign rows, and somebody who never opened anything has no open events.

Why there is no API for this

Erasure runs from the dashboard only — an API key will not authenticate against it. The operation is irreversible and scoped by a single address typed by hand, and a loop that fires it in bulk is far more likely to be a mistake than an intention. If you receive enough requests that clicking through them is genuinely the bottleneck, write to api@quolle.com and tell us what your volume looks like.

Retention, separately

You do not need a request for old data to go. Sending history is deleted automatically once it passes your plan's retention window — the job runs nightly and applies to every account, erasure request or not. Messages are removed a week after the window closes rather than on the day, so that upgrading your plan on day eight still shows you day seven.

Flipbooks are the exception, and deliberately so. Their pages and reading records are not on the retention window: a catalogue is meant to stay readable, and a link sent last quarter should still open. They go when you delete the flipbook, when the account closes, or on a request like this one. If a document has served its purpose, deleting it is the thing that clears the reading data with it.

Recipients asking what happens to their data can be pointed at the privacy policy, which describes the same process from their side.