Concepts de base

RGPD & rétention

Droit à l'effacement

DELETE /v1/actors/:id

Anonymise tous les events d'un acteur donné dans le projet appelant. Les lignes sont conservées pour préserver le lien de chaîne vers les events voisins, mais actor_name, actor_email, metadata, ip_address et user_agent sont mis à null. actor_id est remplacé par [deleted] et anonymized_at est estampillé avec l'heure d'effacement.

bash

curl -X DELETE "https://api.recalled.dev/v1/actors/user_123" \
  -H "Authorization: Bearer $RECALLED_API_KEY"

Passe un query param organization optionnel pour restreindre l'effacement à un seul tenant :

bash

curl -X DELETE "https://api.recalled.dev/v1/actors/user_123?organization=org_acme" \
  -H "Authorization: Bearer $RECALLED_API_KEY"

La vérification est au courant : les lignes avec anonymized_at sont ignorées pendant la recomputation du hash (le payload ne correspond plus au hash stocké, par design), mais le lien de chaîne depuis l'event AVANT et celui APRÈS reste vérifié. L'effacement RGPD satisfait l'Article 17 sans créer d'angle mort pour le tampering.

Rétention

Chaque plan a une rétention par défaut :

Free, 7 jours
Starter, 90 jours
Pro, 1 an (configurable par event avec des règles custom)
Scale, illimitée (configurable par projet)

Sur les plans Pro et Scale, tu peux définir des règles de rétention par pattern d'event depuis les paramètres du projet. user.delete à 10 ans, user.login à 30 jours, * à 1 an, selon ce que ton équipe compliance demande. Sur Pro, ce qui n'est matché par aucune règle retombe sur la rétention plan d'1 an. Sur Scale, ce qui n'est matché reste pour toujours.

Preuve de purge

À chaque fois qu'un batch d'events est supprimé, une ligne est écrite dans retention_checkpoints avec le dernier hash effacé, le compteur, la plage de dates et la raison (plan_retention, rule:<id>, ou project_deleted quand un projet entier est supprimé). L'endpoint verify lit ces checkpoints pour que les trous de chaîne créés par des purges légitimes ne ressemblent pas à du tampering.