When someone asks you to erase them, the request reaches you and not us. You are the controller for the addresses you send here and we are the processor, which means we give you a way to act on the request and a record that it happened.
POST /erasure takes an address and removes every row carrying it, across every batch on your account, including ones still inside their retention window. The response tells you how many rows went and which batches they were in, which is the evidence your privacy log needs.
The erasure record itself is a hash of the address rather than the address. Keeping a plaintext list of people who asked to be forgotten would be a strange way to honor the request, and a hash is enough to answer the only question that matters later: did we action this one.
curl -X POST https://api.zapbounce.com/v1/erasure \
-H "Authorization: Bearer zb_live_..." \
-H "Content-Type: application/json" \
-d '{"email":"ada@example.com","reference":"dsar-2026-0417"}'{
"erasure_id": "era_44b0e7",
"email_sha256": "9f2c...c81a",
"rows_removed": 3,
"batches_affected": ["bat_8f2c1d", "bat_77c204", "bat_12aa90"],
"reference": "dsar-2026-0417",
"completed_at": "2026-09-18T11:14:03Z"
}Fields
| Field | Type | What it carries |
|---|---|---|
| string | The address to erase. Not stored in plaintext after the call completes. | |
| reference | string | Your own case reference, echoed back so the response drops straight into your privacy log. |
| email_sha256 | string | Hash of the erased address. Proof the request was actioned without keeping the address. |
One erasure request, from inbox to privacy log
Say a former lead writes on Monday asking to be erased, and you open a case called dsar-2026-0093. GDPR gives you a month to respond, so there's time to be careful. Remove the person from your CRM and your email platform first, because those are the systems that would mail them again.
Next, call POST /erasure with the address and your case reference. The response shows rows_removed: 2 and two batch ids, and it echoes reference back. Paste that JSON into your privacy log as it is. It records when you acted and how many rows went, and it holds a hash where the address would be.
Finish by adding the address to a do-not-upload list of your own. Erasure here removes stored rows and nothing more. If next quarter's export still contains the person, they'd be uploaded and verified again, so your export job needs that list.
Slips that undo a clean erasure
People often use more than one address. The call takes one at a time. A person who signed up with a work address and a personal one needs two calls, both under the same reference.
Match the form you uploaded. This reference doesn't say whether matching ignores letter case, so don't rely on it. If you lowercase addresses before upload, lowercase them here as well.
Retries are safe. A second call for the same address returns zero rows, and that's still a valid record. Don't treat it as an error in your code.
Watch your own logs. If your HTTP client logs request bodies, the plaintext address of someone who asked to be forgotten now sits in your log tool. That defeats the point of the hash. Turn body logging off for this one call.
Look for exports last of all. Results files saved to laptops and shared drives are outside the reach of any API, and they're the copies an auditor tends to find.
Questions developers ask
Who is the controller?
You are, for the addresses you upload. We process them on your instruction, which is what the data-processing agreement sets out.
How fast does erasure run?
Synchronously for a normal account. The response is the confirmation, not a promise of later work.
What if the address was never on my account?
You get a zero-row response with an erasure id. That is still a useful record: it documents that you checked.
Does this stop future verification of that address?
No. Erasure removes stored rows. If you upload the address again tomorrow it will be verified again, because we cannot tell that submission apart from any other.