Delete a record

When a record is deleted in your system, tell Samesake. Samesake never refuses a delete for billing or limits: a delete is never held for approval, and it isn’t capped. The only refusals are a 404 for an ID Samesake has never had, and a 409 when another request changes the same record at the same moment.

Delete a record

Delete by your own ID:

curl -i -X DELETE https://app.samesake.co.uk/api/v1/records/by-source-id/CRM-10042 \
  -H "X-Api-Key: mk_abcd1234_0123456789abcdefghjkmnpqrstvwxyz"

Try it in the API reference

Or by Samesake’s ID:

curl -i -X DELETE https://app.samesake.co.uk/api/v1/records/rec_7k2m9xq4ht3b \
  -H "X-Api-Key: mk_abcd1234_0123456789abcdefghjkmnpqrstvwxyz"

Try it in the API reference

You get 204 No Content, with no body. Spaces at either end of your own ID are ignored, as they are everywhere in the API.

Status	Meaning
204 No Content	Deleted. This includes a record that was already deleted: deleting twice is fine.
404 Not Found	The source has never had a record with this ID.
409 Conflict	Another request changed the same record at the same moment. Send the delete again.

A delete is safe to repeat. If a delete times out and you don’t know whether it arrived, send it again.

What a delete removes, and what it keeps

Samesake removes everything personal that it holds about the record, straight away:

• the title, names, email address, date of birth, address, postcode and phone numbers;
• the cleaned-up copy it matches on, and the keys it uses to find candidates;
• the comparison details saved with any link, rejected pair or review item that touches the record;
• the record’s details on the People page, until matching regroups the person.

It keeps what holds no personal details: the record’s IDs, its links, the decisions that reviewers made, and the history of what happened to it. That’s why a deleted record can still be read with GET: it comes back with deleted set to true, its details empty and its IDs in place.

Samesake only deletes its own copy. It doesn’t delete anything in your systems, or in your other sources: delete a person’s records in each of them.

Restore a record

Sending a deleted record again brings it back: with POST, PUT, in a batch, or in a file. It keeps its recordId, and matching looks at it again. The outcome in a batch is Updated.

A record that comes back after an erasure request covered it is held out of matching, and flagged for the data protection officer. Concepts explains why.

Delete many records

There’s no bulk delete. You have three options:

• Send a delete for each record, as they’re deleted in your system. Each key can make 600 requests a minute.
• Send a snapshot, a complete list: Samesake deletes every record that isn’t in it. If that would be more than 10% of the source’s records, an admin has to approve it first.
• Upload a CSV file as the complete list. It works the same way.

Erasure requests

If someone has asked to be erased, delete their records in each source. An admin or a data protection officer can then mark the person as “erasure requested” in the app, and Samesake shows which of the person’s records have been deleted and which haven’t. Concepts has the details.