Passer au contenu principal
DELETE

Prise en charge KYC et KYB

Fonctionne pour les sessions de Vérification des utilisateurs (KYC) et de Vérification d’entreprise (KYB). Le session_id est résolu pour les deux types de session, et le comportement de suppression est identique pour les deux. La conservation du gabarit biométrique ne concerne que les sessions KYC, car seules les sessions KYC contiennent un embedding facial.

Comportement

  • La session est supprimée avec toutes les tentatives de vérification qu’elle contient, y compris les résultats remplacés par une nouvelle soumission : sa décision, ses données extraites, ses enregistrements associés aux fonctionnalités (vérifications d’identité, contrôles de registre, documents, AML, analyse IP, etc.), ses examens et son journal d’activité, ainsi que tous ses fichiers stockés.
  • La suppression d’une session Vérification d’entreprise (KYB) supprime aussi, de manière récursive, les vérifications créées pour ses personnes clés (KYC) et ses propriétaires d’entreprise (KYB). La réponse indique leur nombre dans deleted_child_verifications. Une vérification à laquelle la session n’est que liée, comme un KYC approuvé existant qu’elle a réutilisé, n’est pas supprimée.
  • Les données de signature électronique sont supprimées avec la session : les documents à signer et leurs fichiers Word d’origine, les PDF signés, les PDF de preuve, les images de signature et toutes les valeurs des champs. Leurs chemins de téléchargement renvoient 404.
  • La session disparaît immédiatement des réponses de liste et de décision, et les URL des médias émises avant l’appel cessent de fonctionner.
  • Les livraisons de webhook encore en file d’attente pour la session, ainsi que leurs nouvelles tentatives, sont abandonnées.
  • La surveillance AML continue et la surveillance du registre KYB démarrées par les vérifications supprimées s’arrêtent.
  • La suppression est définitive et irréversible. Il n’existe aucun endpoint de restauration : exportez donc tout ce dont vous avez besoin, comme un PDF de décision, avant d’appeler cet endpoint.
  • La réponse est 200 OK, envoyée une fois la suppression terminée, avec un corps JSON qui indique ce qu’il est advenu des données biométriques faciales de la session. Consultez Migration si votre client attend encore un 204.

Données d’un rapport réglementaire finalisé

Si la session fait partie d’un dossier dont le rapport réglementaire est finalisé, la requête renvoie 409 et rien n’est supprimé. La réponse utilise code: in_filed_report et nomme chaque rapport :
Supprimez chaque rapport avec Supprimer le rapport, puis répétez la suppression. La suppression du rapport ne supprime pas la session : celle-ci subsiste jusqu’à ce que vous appeliez de nouveau cet endpoint.

Données biométriques faciales : supprimer ou conserver

Chaque session KYC avec un selfie de détection du vivant contient un embedding facial qui alimente la Recherche faciale 1:N et la détection de doublons. Par défaut, cet embedding est supprimé avec la session (face_retention_policy: delete_with_session). Ainsi, une personne dont vous avez supprimé la session peut vérifier à nouveau son identité sans être signalée comme doublon. Les applications qui ont besoin que la détection de doublons survive à la suppression d’une session peuvent activer la conservation du gabarit biométrique. Didit supprime alors la session et toutes ses données comme d’habitude, et conserve un gabarit biométrique facial distinct, géré séparément et ne contenant aucune image, rattaché à l’utilisateur de la session.
Un gabarit biométrique conservé est une donnée biométrique. Il n’est ni anonyme, ni transitoire, et il n’est pas supprimé avec la session. Il est conservé jusqu’à son expiration programmée, jusqu’à une échéance antérieure imposée par la loi applicable, jusqu’à la suppression de l’utilisateur, jusqu’à une demande d’effacement pour raison de confidentialité, ou jusqu’à une purge explicite. N’activez la conservation que si les instructions de votre responsable du traitement et votre avis de confidentialité la couvrent.
Ce qu’un gabarit conservé contient et ne contient pas : La conservation se configure à trois niveaux, du plus général au plus spécifique :
  1. Politique de l’application dans Business Console → App Settings → Data retention ou via PATCH /v3/webhook/ (face_retention_policy, face_retention_days). Voir Conservation des données.
  2. Dérogation par appel avec retain_face_embeddings sur cet endpoint et sur Suppression de sessions par lot.
  3. Classe d’instruction avec deletion_instruction. Une instruction privacy_erasure l’emporte toujours : elle purge chaque gabarit conservé pour cet utilisateur et n’en conserve jamais de nouveau.

Corps de la requête

Tous les champs sont facultatifs. Omettez le corps pour appliquer la politique de l’application.

Réponse

La réponse confirme que Didit a accepté et appliqué votre instruction de suppression. Ce n’est pas un certificat d’effacement : conservez le instruction_id dans votre propre journal d’effacement afin de pouvoir corréler ultérieurement le journal d’audit.

Durée de conservation et expiration

Chaque gabarit conservé possède une date d’expiration (expires_at) définie. Didit la fixe à la plus proche des échéances suivantes :
  1. face_retention_days de la requête, ou le face_retention_days de l’application lorsque la requête ne le fournit pas ;
  2. la fenêtre générale de conservation des données de l’application, lorsqu’elle est configurée ;
  3. face_retention_deadline de la requête, lorsqu’il est fourni.
Une requête qui conserverait un gabarit sans durée finie est rejetée avec un 400 et rien n’est supprimé. Les gabarits conservés ne peuvent pas dépasser la première échéance parmi : l’instruction client applicable, la fin de la finalité, l’expiration configurée, l’instruction d’effacement de la personne concernée ou l’échéance légale pour les données biométriques. Vous êtes responsable du choix d’une durée conforme aux lois applicables à vos utilisateurs ; choisissez une durée plus courte chaque fois qu’une règle applicable l’exige.

Effacement au titre de la vie privée

Envoyez deletion_instruction: "privacy_erasure" lorsque vous agissez à la suite d’une demande de la personne concernée. Didit purge chaque gabarit biométrique conservé rattaché à l’Utilisateur de la session, puis supprime la session et son embedding facial. La politique de conservation de l’application ne peut pas prévaloir sur une instruction d’effacement pour motif de confidentialité, et retain_face_embeddings: true est rejeté avec 400. Supprimer l’Utilisateur avec la suppression par lots des utilisateurs purge également ses gabarits conservés.

Ce qui n’est pas affecté

La suppression d’une session ne nettoie pas les éléments suivants à votre place. Si vous traitez une demande d’effacement, gérez-les séparément.
  • Les entrées de la liste de blocage créées à partir de la session (visage ou document) restent en place. Supprimez-les depuis la liste de blocage. Une entrée de liste de blocage faciale conserve sa propre entrée biométrique, indépendante de tout gabarit conservé.
  • Les jetons de partage déjà émis pour la session ne sont pas révoqués, mais il n’y a plus rien à importer : une importation avec l’un de ces jetons renvoie 400 avec {"share_token": ["Original session does not exist."]}.
  • Les webhooks déjà livrés pour la session ne sont pas affectés. Les livraisons encore en file d’attente, ainsi que leurs nouvelles tentatives, sont abandonnées. Aucun webhook n’est émis pour la suppression elle-même.
  • Les crédits déjà consommés par la vérification ne sont pas remboursés.
  • Les copies signées déjà envoyées par e-mail à un signataire lors d’une étape de signature électronique se trouvent dans la boîte de messagerie du signataire et ne sont pas affectées.
  • L’entité parente Utilisateur ou Entreprise n’est pas supprimée. Utilisez Supprimer des utilisateurs ou Supprimer des entreprises pour ceux-ci. Si le portrait de profil de l’Utilisateur provient de la session supprimée, ce portrait est supprimé.
  • Un gabarit biométrique conservé (uniquement si vous avez choisi cette option) reste en place jusqu’à son expiration ou jusqu’à ce que vous le purgiez. Purgez-le avec l’API des gabarits biométriques, en supprimant l’Utilisateur, ou en répétant la suppression d’une autre session du même Utilisateur avec deletion_instruction: "privacy_erasure".

Exemples

Réponse d’une application qui n’a pas activé cette option :

Erreurs

Sur 400, rien n’est supprimé. Sur 503, la session est toujours en place : répétez la même requête jusqu’à obtenir 200. Certains de ses fichiers stockés ou son embedding facial peuvent déjà être supprimés ; ne vous y fiez pas après un 503.

Autorisation

Requiert delete:sessions. La même autorisation couvre les sessions de vérification des utilisateurs (KYC) et de vérification d’entreprise (KYB), ainsi que la dérogation de conservation.

Suppression par lots

Pour les opérations en masse sur des sessions KYC, utilisez POST /v3/sessions/delete/. Il accepte les mêmes champs de conservation et d’instruction. Jusqu’à 20 sessions correspondantes sont supprimées dans la requête, avec un résultat par session ; au-delà, elles sont traitées sous forme de tâche de suppression. Consultez Suppression par lots de sessions.

Migration depuis les réponses 204

Jusqu’à cette version, l’endpoint renvoyait 204 No Content. Il renvoie désormais 200 OK avec le corps JSON décrit ci-dessus, afin que chaque suppression indique son face_retention_outcome. Mettez à jour les clients qui vérifient que la réponse est 204. Le comportement par défaut est inchangé : les applications existantes restent sur delete_with_session, et aucune migration n’active la conservation à votre place. Activez-la explicitement dans la Console ou via PATCH /v3/webhook/.

Voir aussi

Autorisations

x-api-key
string
header
requis

La clé API de votre application, issue de Développeurs -> Clés API dans la Business Console. La clé principale dispose d'un accès complet. Une clé nommée peut être restreinte : aucun, lecture ou écriture par ressource, limitée à certains workflows ou aux sessions approuvées, à une liste d'adresses IP et à une date d'expiration. 401 signifie que la clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a été envoyée, que la clé n'a pas accès à cette ressource ou action, ou que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur une route de session signifie que la session est hors des workflows ou des statuts de la clé. Une clé sans accès aux médias reçoit les URL d'images, de vidéos et de PDF à null, et une clé sans accès en écriture aux sessions reçoit les liens et tokens de session à null. Voir https://docs.didit.me/console/api-keys.

Paramètres de chemin

sessionId
string<uuid>
requis

UUID (session_id) de la session de Vérification des utilisateurs (KYC) ou de Vérification d'entreprise (KYB) à supprimer, tel que renvoyé lors de la création de la session. Doit être un UUID canonique avec traits d'union — une valeur qui n'est pas un UUID ne correspond pas à la route et renvoie 404.

Exemple:

"11111111-2222-3333-4444-555555555555"

Corps

application/json

Optionnel. Omettez entièrement le corps pour suivre la politique de conservation de l'application avec une suppression opérationnelle.

retain_face_embeddings
boolean | null

Remplacer la face_retention_policy de l'application pour cette suppression. true conserve un gabarit biométrique facial sans image rattaché à l'utilisateur de la session après la suppression de la session ; false supprime l'embedding facial avec la session ; omettez ou définissez sur null pour suivre la politique de l'application. Ignoré pour les sessions KYB et pour les sessions sans embedding facial.

Exemple:

true

face_retention_days
integer

Durée de conservation finie, en jours, pour un gabarit conservé. Requise lorsqu'un gabarit est conservé, sauf si l'application définit déjà face_retention_days. La valeur expires_at du gabarit correspond à la date d'expiration la plus proche, déterminée par cette durée, la fenêtre générale de conservation des données de l'application et face_retention_deadline.

Plage requise: 1 <= x <= 3650
Exemple:

365

face_retention_deadline
string<date-time>

Expiration stricte optionnelle pour un modèle conservé. Doit être dans le futur.

Exemple:

"2027-08-28T00:00:00Z"

deletion_instruction
enum<string>
défaut:operational_session_delete

La catégorie d'instruction que vous donnez. operational_session_delete supprime la session et ne conserve un modèle que si la politique ou retain_face_embeddings l'indique. privacy_erasure purge tout gabarit biométrique conservé ancré à l'Utilisateur de la session avant de supprimer la session, ne peut pas être outrepassé par la politique de l'application, et ne peut pas être combiné avec retain_face_embeddings: true (400).

Options disponibles:
operational_session_delete,
privacy_erasure
Exemple:

"operational_session_delete"

instruction_id
string

Votre référence durable pour cette instruction de suppression (par exemple un ID de ticket d'effacement). Enregistrée dans le journal d'audit et sur tout gabarit conservé. Générée par Didit lorsqu'elle est omise.

Maximum string length: 255
Exemple:

"dsar-2026-0142"

Réponse

Session supprimée. Le corps indique ce qui est advenu des données biométriques faciales de la session et, pour une session KYB, combien de vérifications qu'elle a créées ont été supprimées avec elle.

session_id
string<uuid>

La session supprimée.

session_number
integer | null

Le numéro de la session supprimée.

face_retention_outcome
enum<string>

Ce qui est advenu des données biométriques faciales de la session. deleted : l'embedding facial a été supprimé avec la session (par défaut). retained_with_user : la session est supprimée et un gabarit biométrique sans image reste rattaché à l'User ; voir biometric_template_uuid. none : la session ne comportait aucun embedding facial (par exemple une session KYB, ou une session KYC sans selfie de détection du vivant). ineligible_no_vendor_user : la conservation a été demandée mais la session n'a aucun User lié, l'embedding a donc été supprimé avec la session. Un échec du stockage biométrique n'est jamais signalé via ce champ sur cet endpoint : il renvoie 503 et la session n'est pas supprimée.

Options disponibles:
retained_with_user,
deleted,
none,
ineligible_no_vendor_user
biometric_template_uuid
string<uuid> | null

Identifiant du gabarit biométrique conservé lorsque face_retention_outcome vaut retained_with_user ; null sinon. Gérez-le via /v3/biometric-templates/{template_uuid}/.

biometric_template_expires_at
string<date-time> | null

Moment où le gabarit biométrique conservé est supprimé, lorsque face_retention_outcome vaut retained_with_user ; null lorsqu'aucun gabarit n'est conservé.

deleted_child_verifications
integer

Pour une session de Vérification d'entreprise (KYB) : combien de vérifications créées par celle-ci (les sessions KYC de ses personnes clés et les sessions KYB de ses entités propriétaires, de manière récursive) ont été supprimées avec elle. Vaut toujours 0 pour une session KYC.

Dernière modification le 7 novembre 2026