Privacy and erasure

When a person asks your customer to forget them, one call to erase a person removes everything we hold about them in that workspace: the contact, the email we sent them, and the data of the events you emitted for them. We keep only a one-way hash of their address, so they don’t get marketing email from that workspace again unless they sign up again.

Erasing a person

Name the contact, by your reference or our id:

curl -X POST https://api.sendtruss.com/v1/workspaces/ref:cust_4821/erasures \
  -H "Authorization: Bearer $SENDTRUSS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contact": "ref:guest_998"}'

Or give an email address, for someone you sent transactional email to who was never a contact:

curl -X POST https://api.sendtruss.com/v1/workspaces/ref:cust_4821/erasures \
  -H "Authorization: Bearer $SENDTRUSS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "ana@example.com"}'

Send one or the other, not both. An address a contact holds erases that contact.

The answer is a 202 with the erasure’s id and requested_at. The erasure itself runs straight after the answer, and finishes even if something interrupts it.

What it removes

• The contact, with its attributes, tags and consent.
• Every email we sent the person in that workspace, its content included.
• The record of every outcome of those emails.
• For each event you emitted for them: the payload, the idempotency key, and every link to the person. The event’s type and time stay, so “a booking was made in this workspace on 12 March” is still counted, but nothing says by whom.
• The address from the suppression list, replaced by the hash below.

An erasure covers one workspace. If the same person is a contact in two of your customers’ workspaces, erase them in each.

What it keeps

A hash of the address, made with a secret key, so it can’t be turned back into the address or matched against a list of guesses. It’s how we keep the promise: no marketing email reaches that address in that workspace again. If the person later signs up again through your platform, send a subscribed consent dated after the erasure, and they’re back on the list. That doesn’t hold for an address that had bounced or complained before it was erased: consent never lifts a suppression.

Transactional email still reaches an erased address. A booking confirmation presupposes a new booking, and refusing it would harm the person the erasure protects. The exception is an address that had hard-bounced: it stays blocked for all email, since it still doesn’t exist.

Erasing a person sends no webhook. Your backend asked for it.

Delete or erase

Delete a contact is for managing your own records: the contact and its tags go, the email we already sent them stays until it ages out, and no hash is kept, so if they book again next year they can be marketed to as soon as you send their consent. Erase is for a person’s request to be forgotten.

How long we keep things

We drop stored data a calendar month at a time, and the current month counts. So the content of each email and each event’s payload last between one and two months, depending on when in the month they were written. The record that an email was sent, with its outcomes, and the event itself last between 12 and 13 months. Webhooks can be listed for 30 days. A deleted workspace’s contacts and history are removed 30 days after the delete.

Consent you collect

Consent is yours and your customers’ to collect, never ours to assume. That’s why a contact you never send consent for gets no marketing, and why each consent carries the time it was given and the key that sent it. See Contacts, attributes and consent.