Deleting data
Soft and immediate deletes, per-photo removal, selfie and user deletes, restore windows, the deletion status endpoint, and how to satisfy an erasure request.
SightRadar stores faceprints, never your photos. Deleting a collection, a photo's faceprints or a user's selfies 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.
A plain delete of a collection that still holds faces can be refused with 409 and code: confirmation_required while the destructive-intent guard is switched on. Retry with ?intent=erase to confirm; immediate and compliance deletes already carry that intent and are never refused this way.
Reusing a deleted id
A purged collection keeps its id reserved: POST /v1/collections and new writes to it return 409. POST /v1/collections/{id}/recreate brings it back as a new, empty collection once the purge is verified complete. It refuses with 409 while the old collection still has deletion or batch work in flight, and always refuses a collection erased under ?compliance=true.
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.
Selfie and user deletes
Registered selfies have their own deletes, separate from the photo faces:
| Call | Removes |
|---|---|
DELETE /v1/collections/{id}/selfies/{selfieId} | Every stored version of one selfie, by the selfieId you registered it with. Add ?userId= to remove only the copy registered under that user. |
DELETE /v1/collections/{id}/users/{userId} | Every selfie registered under that userId in the collection. |
Both are free and synchronous, and they behave differently from the photo delete:
- Immediate only. There is no soft mode, no grace window and no restore. The selfie is removed before the
200comes back. - Verified. A
200means no matching selfie remains. If one is still stored, the response is503withRetry-After: 1; retry the same call. A503withRetry-After: 30means deletes are briefly paused on our side; wait that long, then retry. Always honour the header. - Idempotent. An unknown or already-deleted id returns
200withdeleted: [], so retries are safe. - Audited. Each call is recorded as a
selfie.deleteoruser.deleteaudit event.?compliance=truemarks it as a compliance-class erasure; the delete itself is the same.
Ids are limited to 512 bytes; a longer id, or an empty ?userId=, returns 400. A collection that does not exist, belongs to another account, or is deleted or deleting returns 404. The 200 body lists the removed point_ids in deleted, plus deleted_selfie_ids and deleted_user_ids (schema). After the delete, search-by-id on one of those point ids returns reason: "point_not_found".
A user delete does not touch indexed photos: SightRadar keeps no link between a user and the faces in your photos. To remove a person from the photos they appear in, delete those photos.
Confirming an erasure
Collection 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:
{ "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).
An erasure request, end to end
photoIds. If they registered a selfie, note their userId.?compliance=true: the collection delete, or the photo deletes plus DELETE /v1/collections/{id}/users/{userId}.202: poll the deletion status until phase is completed and verified_zero is true, or wait for the webhook. Photo and user deletes finish inside the call.workflow_id and completed_at for a collection delete; for photo and user deletes, the 200 body (the removed point_ids in deleted) and the time of the call. 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 and /dpa.
Choosing a similarity threshold
Turn a 0 to 1 cosine similarity into accept, review and reject decisions using your own data, not a number copied from another vendor.
Migrate from AWS Rekognition
What is drop-in, what changes, the one step nobody can skip, and a six-step runbook for cutting over without a big-bang switch.