# Deleting data

> Soft and immediate deletes, per-photo removal, restore windows, the deletion status endpoint, and how to satisfy an erasure request.

Source: https://sightradar.com/docs/guides/deleting-data

SightRadar stores faceprints, never your photos. Deleting a collection or a photo's faceprints is the whole retention story on our side; the images stay wherever you keep them.

## Two modes

| Mode           | How                                           | Restorable?                         | Use when                                                                                                                             |
| -------------- | --------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Soft (default) | `DELETE /v1/collections/{id}`                 | Yes, until the grace window elapses | Normal lifecycle: an event is over, a tenant churned.                                                                                |
| Immediate      | `DELETE /v1/collections/{id}?immediate=true`  | No                                  | You need the vectors gone now.                                                                                                       |
| Compliance     | `DELETE /v1/collections/{id}?compliance=true` | No                                  | An erasure request under GDPR, BIPA or similar. Same as immediate, plus recorded as a compliance-class erasure for your audit trail. |

A soft-deleted collection stops accepting index and search **immediately**; nothing is erased until `purge_after`. `POST /v1/collections/{id}/restore` undoes it any time before the purge starts. Once `status` is `deleting`, restore returns `409`.

## Per-photo deletes

`DELETE /v1/collections/{id}/photos/{photoId}` removes the faceprints indexed from one photo, by the `photoId` you supplied at index time. It is synchronous, free and idempotent, and supports the same `immediate` and `compliance` flags. Soft-deleted faces drop out of search at once and can be restored with `POST /v1/collections/{id}/photos/{photoId}/restore` while the grace window lasts.

There is no per-face delete. The finest granularity is the photo.

## Confirming an erasure

Deletes return `202`: the erasure runs as a workflow afterwards. Do not close a ticket on the `202`. Poll `GET /v1/collections/{id}/deletion` until:

```json
{ "phase": "completed", "verified_zero": true, "deletion_class": "compliance", "completed_at": "…" }
```

`verified_zero: true` means the engine has re-checked the collection's vector store and found nothing. If you have a webhook registered, the same moment arrives as a signed `collection.deletion.completed` event ([schema](/docs/api/webhooks/register-a-webhook-endpoint)).

## An erasure request, end to end

Identify the collection(s) and, if the person is one photo among many, the 

`photoId`

s.

Issue the delete with 

`?compliance=true`

.

Poll the deletion status until 

`phase`

is 

`completed`

and 

`verified_zero`

is 

`true`

, or wait for the webhook.

Record 

`workflow_id`

and 

`completed_at`

in your own log. Delete the source images from your storage.

Detect and compare never persist anything, so there is nothing to erase from those operations. Retention commitments and the data processing agreement are at [/trust](/trust) and [/dpa](/dpa).