> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # API de suppression de session : droit à l'oubli RGPD > Supprimez une session KYC/KYB et ses données avec Didit. Par défaut, l'embedding facial est aussi effacé ; un gabarit sans image peut être conservé. Prompt de suppression de session Copier le prompt dans le presse-papiers \

\`Delete a single Didit verification session and all of its data, and control what happens to the face biometric data.

Endpoint:
DELETE https://verification.didit.me/v3/session/{session_id}/delete/

Authentication:
Use the x-api-key header with your Didit API key. Privilege: delete:sessions.

Path parameter:
\- session_id (UUID) — works for both User Verification (KYC) and Business Verification (KYB) sessions. Didit resolves the id against both session types.

Optional JSON body (send Content-Type: application/json; omit the body entirely for the default behavior):
\- retain_face_embeddings (boolean | null) — override the application's face_retention_policy for this deletion. true keeps an image-free biometric template anchored to the session's User; false deletes the face embedding with the session; omit or null to follow the application policy.
\- face_retention_days (integer 1-3650) — finite retention duration for the template. Required when retaining unless the application already sets face_retention_days.
\- face_retention_deadline (ISO 8601 datetime, future) — optional hard expiry. The template expires at the earliest of face_retention_days, the application's data-retention window, and this deadline.
\- deletion_instruction ("operational_session_delete" default | "privacy_erasure") — privacy_erasure purges every retained biometric template for the session's User and never retains a new one, regardless of the application policy. Combining privacy_erasure with retain_face_embeddings: true is rejected with 400.
\- instruction_id (string, max 255) — your own durable reference for this deletion instruction (for example your erasure-ticket id). Stored on the audit trail and on any retained template.

curl examples:
Default (follow the application policy; delete_with_session unless you opted in):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: "

Delete the session but keep an image-free biometric template for 365 days:
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"retain_face_embeddings": true, "face_retention_days": 365}'

Right-to-erasure request (delete the session AND purge every retained template for that person):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'

Response: 200 OK with a JSON body once the deletion has completed (this endpoint no longer returns 204):
\{
"session_id": "",
"session_number": 1024,
"face_retention_outcome": "deleted" | "retained_with_user" | "none" | "ineligible_no_vendor_user",
"biometric_template_uuid": "" | null,
"biometric_template_expires_at": "" | null,
"deleted_child_verifications": 0
}
\- deleted: the session and its face embedding are deleted (default behavior).
\- retained_with_user: the session is deleted; an image-free biometric template with the returned biometric_template_uuid stays anchored to the User until biometric_template_expires_at, User deletion, privacy erasure, or explicit purge. Manage it with GET/DELETE /v3/biometric-templates/{uuid}/.
\- none: the session had no face embedding (for example a KYB session or a document-only KYC session).
\- ineligible_no_vendor_user: retention was requested but the session has no linked User (no vendor_data), so nothing can anchor the template. The session and its embedding are deleted.
\- biometric_template_expires_at: when the retained template is deleted; null when no template is retained.
\- deleted_child_verifications: for a KYB session, how many verifications it created (its key people's KYC sessions and its corporate owners' KYB sessions, recursively) were deleted with it. Always 0 for a KYC session.

Behavior:
\- The session and every verification attempt it holds are deleted, including results a resubmission replaced: the decision, the extracted data, the associated feature records (ID verification, registry checks, documents, AML, IP, etc.), its reviews and activity log, and all stored files (document images, videos, portraits, selfies, POA documents, extra uploads, and E-signature documents, signed PDFs, evidence PDFs and signature images).
\- A KYB session is deleted together with the verifications it created for its key people and corporate owners. A verification it only links to (for example a reused, already approved KYC) is not deleted.
\- The session disappears immediately from /v3/sessions/ and /v3/session/{id}/decision/, and media URLs issued before the call stop resolving.
\- Webhook deliveries still queued for the session, and their retries, are dropped. Webhooks already delivered are not affected.
\- Ongoing AML monitoring and KYB registry monitoring started by the deleted verifications stop.
\- A retained biometric template never contains the face image, liveness video, document data, extracted identity fields, the decision, or the deleted session's id. It is biometric data, tenant-scoped, used only for your duplicate-face, multi-account, biometric-authentication, and list matching, and it is never used for model training or cross-customer fraud processing.
\- Share tokens issued for the session are NOT revoked, but there is nothing left for them to import: an import with one returns 400 {"share_token": ["Original session does not exist."]}.
\- Blocklist entries created from the session are NOT removed; manage those with the Lists endpoints.
\- Credits already consumed by the verification are NOT refunded.
\- The parent User or Business entity is NOT deleted; use POST /v3/users/delete/ or POST /v3/businesses/delete/ for those. Deleting the User also purges its retained biometric templates. If the User's profile portrait came from this session, the portrait is removed.
\- No webhook fires for the deletion itself.

Idempotency:
Idempotent in effect: the second call to the same session returns 404 because the session no longer exists. Deletion is permanent and cannot be undone.

Failure modes:
\- 400: {"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]} or {"detail": "A finite biometric-template retention duration is required."} (retention requested without face_retention_days on the request or the application). Nothing is deleted.
\- 403: {"detail": "You do not have permission to perform this action."} when the key lacks delete:sessions.
\- 404: {"detail": "Not found."} when the session does not exist (or was already deleted).
\- 409: {"detail": "...", "code": "in_filed_report", "reports": [{"uuid": "...", "report_number": "SAR-0001", "report_type": "SAR", "case_uuid": "..."}]} when the session is part of a finalized regulatory report. Nothing is deleted. Delete the reports, then repeat the request.
\- 503: {"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."} or {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} The session is still in place; repeat the same request until it returns 200. Some of its stored files or its face embedding may already be deleted. Retries converge on a single template.

Bulk delete:
For many KYC sessions at once, use POST /v3/sessions/delete/ with body {"session_numbers": ["1001", "1002"]} or {"delete_all": true}; it accepts the same retention and instruction fields. Up to 20 matching sessions return 200 with a per-session outcome; more return 202 with a job to poll at GET /v3/sessions/delete/{job_id}/.

Migration note:
Until this release the endpoint returned 204 No Content. It now returns 200 OK with the JSON body above. Update clients that assert on 204. The default deletion behavior is unchanged: existing applications stay on delete_with_session until you explicitly change the policy.

When to call:
\- Customer requests data erasure (GDPR Article 17): use deletion_instruction: "privacy_erasure".
\- Operational clean-up after approval while keeping duplicate detection: retain_face_embeddings: true with a finite face_retention_days.
\- Cleaning up test sessions from a staging application.
\- After exporting a decision PDF for long-term archival outside Didit.

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
Coller dans ## Prise en charge KYC et KYBFonctionne 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](#migration-depuis-les-réponses-204) 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 :```json theme={null} { "detail": "This session is part of a finalized regulatory report, so it cannot be deleted.", "code": "in_filed_report", "reports": [ { "uuid": "5ec00000-0000-4000-8000-000000000007", "report_number": "SAR-0001", "report_type": "SAR", "case_uuid": "c1a5e000-0000-4000-8000-000000000001" } ] } ```Supprimez chaque rapport avec [Supprimer le rapport](https://docs.didit.me/fr/management-api/regulatory-reports/delete.md), 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 conserverChaque session KYC avec un selfie de détection du vivant contient un embedding facial qui alimente la [Recherche faciale 1:N](https://docs.didit.me/fr/core-technology/face-search/overview.md) 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](https://docs.didit.me/fr/entities/users/overview.md) de la session.> [!WARNING] > > 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 :| Conservé | Jamais conservé | | - | - | | Le gabarit facial numérique utilisé pour la correspondance | L'image du visage, la vidéo de détection du vivant, les images de documents, les recadrages de portrait et tout autre média | | Un nouvel identifiant aléatoire de gabarit et un `provenance_reference` opaque | L'identifiant, le numéro, la décision, les champs d'identité extraits ou les payloads de caractéristiques de la session supprimée | | L'utilisateur propriétaire (`vendor_user_uuid`, `vendor_data` actuel) | L'état de la liste de blocage, les correspondances antérieures, les étiquettes de fraude ou les revendications d'identité inter-organisations | | Métadonnées de conservation : `retained_at`, `expires_at`, politique, dérogation, classe d'instruction, `instruction_id` et l'identifiant du principal ayant agi | Les adresses e-mail des acteurs |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](https://docs.didit.me/fr/console/data-retention.md#conservation-des-gabarits-biométriques). 2) **Dérogation par appel** avec `retain_face_embeddings` sur cet endpoint et sur [Suppression de sessions par lot](https://docs.didit.me/fr/management-api/sessions/batch-delete.md). 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êteTous les champs sont facultatifs. Omettez le corps pour appliquer la politique de l'application.| Champ | Type | Description | | - | - | - | | `retain_face_embeddings` | booléen ou null | Remplace la politique de l'application pour cette suppression. `true` conserve un gabarit, `false` supprime l'embedding avec la session, `null` ou absent suit la politique. | | `face_retention_days` | entier (1-3650) | Durée de conservation finie du gabarit. Obligatoire lorsqu'un gabarit est conservé, sauf si l'application définit déjà `face_retention_days`. | | `face_retention_deadline` | datetime (ISO 8601) | Expiration stricte facultative. Doit être dans le futur. | | `deletion_instruction` | `operational_session_delete` (par défaut) ou `privacy_erasure` | La classe d'instruction que vous donnez. `privacy_erasure` purge chaque gabarit conservé pour l'utilisateur de la session avant de supprimer la session, et ne peut pas être combiné avec `retain_face_embeddings: true`. | | `instruction_id` | chaîne (255 caractères max) | Votre référence durable pour cette instruction, par exemple l'identifiant de votre ticket d'effacement. Inscrite dans le journal d'audit et sur tout gabarit conservé. Si vous l'omettez, Didit en génère une, visible dans le détail du gabarit. |### Réponse```json theme={null} { "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02", "session_number": 1024, "face_retention_outcome": "retained_with_user", "biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b", "biometric_template_expires_at": "2027-10-09T10:15:00Z", "deleted_child_verifications": 0 } ```| Champ | Description | | - | - | | `session_id` | La session supprimée. | | `session_number` | Le numéro de la session supprimée. | | `face_retention_outcome` | Ce qui est advenu des données biométriques faciales de la session. Voir le tableau ci-dessous. | | `biometric_template_uuid` | Identifiant du gabarit biométrique conservé lorsque `face_retention_outcome` vaut `retained_with_user`, `null` sinon. | | `biometric_template_expires_at` | Moment où le gabarit biométrique conservé est supprimé, `null` lorsqu'aucun gabarit n'est conservé. | | `deleted_child_verifications` | Pour une session KYB, nombre de vérifications qu'elle a créées (les sessions KYC de ses personnes clés et les sessions KYB de ses propriétaires d'entreprise, récursivement) et qui ont été supprimées avec elle. Toujours `0` pour une session KYC. || `face_retention_outcome` | Signification | | - | - | | `deleted` | La session et son embedding facial sont supprimés. Comportement par défaut. | | `retained_with_user` | La session est supprimée. Un gabarit biométrique sans image reste rattaché à l'utilisateur ; son identifiant est `biometric_template_uuid`. Gérez-le avec l'[API des gabarits biométriques](https://docs.didit.me/fr/management-api/biometric-templates/overview.md). | | `none` | La session n'avait aucun embedding facial à supprimer ou à conserver (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'est pas liée à un utilisateur (elle a été créée sans `vendor_data`), donc rien ne peut servir d'ancrage à un gabarit. La session et son embedding sont supprimés. Le résultat non éligible est consigné dans le journal d'audit. |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 expirationChaque 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éeEnvoyez `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](https://docs.didit.me/fr/management-api/users/delete.md) 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](https://docs.didit.me/fr/entities/users/blocklist.md). 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](https://docs.didit.me/fr/sessions-api/share-session/import.md) 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](https://docs.didit.me/fr/management-api/users/delete.md) ou [Supprimer des entreprises](https://docs.didit.me/fr/management-api/businesses/delete.md) 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](https://docs.didit.me/fr/management-api/biometric-templates/purge.md), 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> [tab] Par défaut (politique de l'application) > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \ > -H "x-api-key: YOUR_API_KEY" > ``` > > Réponse d'une application qui n'a pas activé cette option : > > ```json theme={null} > { > "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02", > "session_number": 1024, > "face_retention_outcome": "deleted", > "biometric_template_uuid": null, > "biometric_template_expires_at": null, > "deleted_child_verifications": 0 > } > ```> [tab] Conserver un gabarit biométrique > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{"retain_face_embeddings": true, "face_retention_days": 365, "instruction_id": "cleanup-2026-08-0142"}' > ``` > > ```json theme={null} > { > "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02", > "session_number": 1024, > "face_retention_outcome": "retained_with_user", > "biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b", > "biometric_template_expires_at": "2027-10-09T10:15:00Z", > "deleted_child_verifications": 0 > } > ```> [tab] Forcer la suppression sur une application ayant activé l'option > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{"retain_face_embeddings": false}' > ``` > > ```json theme={null} > { > "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02", > "session_number": 1024, > "face_retention_outcome": "deleted", > "biometric_template_uuid": null, > "biometric_template_expires_at": null, > "deleted_child_verifications": 0 > } > ```> [tab] Effacement à des fins de confidentialité > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}' > ``` > > Tous les gabarits conservés pour l'Utilisateur de la session sont d'abord purgés, puis la session est supprimée : > > ```json theme={null} > { > "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02", > "session_number": 1024, > "face_retention_outcome": "deleted", > "biometric_template_uuid": null, > "biometric_template_expires_at": null, > "deleted_child_verifications": 0 > } > ```> [tab] Session sans utilisateur > > Une session créée sans `vendor_data` n'a pas d'Utilisateur auquel rattacher un gabarit : > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/7a1e9c2d-.../delete/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{"retain_face_embeddings": true, "face_retention_days": 365}' > ``` > > ```json theme={null} > { > "session_id": "7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c", > "session_number": 1031, > "face_retention_outcome": "ineligible_no_vendor_user", > "biometric_template_uuid": null, > "biometric_template_expires_at": null, > "deleted_child_verifications": 0 > } > ```> [tab] Session de vérification d'entreprise (KYB) > > ```bash theme={null} > curl -X DELETE https://verification.didit.me/v3/session/bs-01HJX1.../delete/ \ > -H "x-api-key: YOUR_API_KEY" > ``` > > La vérification d'entreprise est supprimée avec les trois vérifications créées pour ses personnes clés : > > ```json theme={null} > { > "session_id": "0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b", > "session_number": 88, > "face_retention_outcome": "none", > "biometric_template_uuid": null, > "biometric_template_expires_at": null, > "deleted_child_verifications": 3 > } > ```## Erreurs| Statut | Cas | Corps | | - | - | - | | `400` | `privacy_erasure` combiné à `retain_face_embeddings: true` | `{"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]}` | | `400` | Conservation demandée sans durée finie, sur la requête ou sur l'application | `{"detail": "A finite biometric-template retention duration is required."}` | | `403` | Les identifiants ne disposent pas de `delete:sessions` ou ne possèdent pas la session | `{"detail": "You do not have permission to perform this action."}` | | `404` | Session inconnue ou déjà supprimée | `{"detail": "Not found."}` | | `503` | Un service de stockage ou un fournisseur de surveillance était indisponible pendant la suppression de la session. | `{"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."}` | | `503` | Un système de stockage biométrique était indisponible pendant la conservation ou la purge d'un gabarit. Les nouvelles tentatives convergent vers un gabarit unique. | `{"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."}` |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`.## AutorisationRequiert `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 lotsPour 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](https://docs.didit.me/fr/management-api/sessions/get-deletion-job.md). Consultez [Suppression par lots de sessions](https://docs.didit.me/fr/management-api/sessions/batch-delete.md).## Migration depuis les réponses 204Jusqu'à 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- [Gabarits biométriques](https://docs.didit.me/fr/management-api/biometric-templates/overview.md) - [Conservation des données](https://docs.didit.me/fr/console/data-retention.md) - [Vue d'ensemble des sessions](https://docs.didit.me/fr/sessions-api/overview.md) ## OpenAPI ````yaml fr/openapi-25.json DELETE /v3/session/{sessionId}/delete/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/delete/: delete: tags: - Sessions summary: Supprimer une session de vérification (KYC ou KYB) description: "Supprimez une session de vérification unique, Vérification des utilisateurs (KYC) ou Vérification d'entreprise (KYB), par son `session_id`. L'identifiant est d'abord résolu parmi les sessions KYC, puis les sessions KYB, de sorte que les deux types sont supprimés via cette URL unique.\n\n**Ce qui est supprimé\_:**\n- La session et chaque tentative de vérification qu'elle contient, y compris les résultats remplacés par une nouvelle soumission\_: la décision, les données extraites, tous les enregistrements de fonctionnalités associés (vérification d'identité, visage, détection du vivant, correspondance faciale, filtrage AML, vérifications de registre, analyse de l'IP, etc.), ses examens et son journal d'activité.\n- Tous les fichiers stockés appartenant à la session\_: photos recto/verso du document (versions intégrales, recadrées et floutées pour des raisons de confidentialité), vidéos de capture du document, recadrages de portrait, images de portrait et de signature de la puce NFC, images de référence du visage, vidéos de détection du vivant, images source/cible de correspondance faciale, justificatifs de domicile et tout fichier supplémentaire importé (KYC)\_; documents d'entreprise importés et fichiers supplémentaires (KYB). Documents de signature électronique, PDF signés, PDF de preuves et images de signature (KYC et KYB)\_: leurs chemins de téléchargement cessent de fonctionner. Les URL de médias précédemment émises (`https:///...`) ne sont plus résolues.\n- Les données faciales de la session. Son embedding facial est également supprimé, sauf si vous choisissez de conserver un gabarit sans image (voir **Données biométriques faciales**).\n- Les livraisons de webhooks encore en file d'attente pour la session, ainsi que leurs réessais. Les webhooks déjà livrés ne sont pas affectés.\n- Pour une session de Vérification d'entreprise (KYB)\_: les vérifications créées pour ses personnes clés (KYC) et ses propriétaires personnes morales (KYB), de manière récursive, signalées sous `deleted_child_verifications`. Une vérification à laquelle elle est uniquement liée, comme un KYC approuvé existant qu'elle a réutilisé, n'est pas supprimée.\n\nLa session disparaît immédiatement de tous les endpoints de lecture\_: `GET /v3/session/{sessionId}/decision/` renvoie `404` et `GET /v3/sessions/` cesse de la lister. La surveillance AML continue et la surveillance de registre KYB initiées par les vérifications supprimées s'arrêtent.\n\n**Ce qui n'est pas affecté\_:** les entrées de liste de blocage créées à partir de cette session (visage ou document) ne sont **pas** supprimées\_; gérez-les avec les endpoints de liste de blocage. Les tokens de partage émis pour la session ne sont pas révoqués, mais ils n'ont plus rien à importer\_: un import avec l'un d'eux renvoie `400` avec `{\"share_token\": [\"Original session does not exist.\"]}`. Les crédits déjà consommés ne sont **pas** remboursés. L'entité parente Utilisateur ou Entreprise n'est **pas** supprimée\_; utilisez `POST /v3/users/delete/` ou `POST /v3/businesses/delete/` pour celles-ci. Si le portrait de profil de l'utilisateur provenait de cette session, le portrait est supprimé avec elle.\n\n**Données biométriques faciales\_:** par défaut, l'embedding facial de la session est supprimé avec la session (`face_retention_outcome: deleted`). Une application ayant activé la conservation du gabarit biométrique (`face_retention_policy: retain_until_user_deleted` sur `PATCH /v3/webhook/`), ou une requête avec `retain_face_embeddings: true`, conserve un gabarit biométrique facial sans image géré séparément, associé à l'utilisateur de la session (`retained_with_user`), afin que la détection de doublons, la Recherche faciale et l'authentification biométrique continuent de fonctionner. Le gabarit ne contient jamais l'image du visage, les médias, les champs d'identité, la décision ni l'identifiant de la session supprimée\_; il s'agit de données biométriques supprimées à `biometric_template_expires_at`, ou plus tôt lors de la suppression de l'utilisateur, d'un effacement pour raisons de confidentialité ou d'une purge explicite via `/v3/biometric-templates/`. Une session sans utilisateur associé ne peut pas conserver de gabarit (`ineligible_no_vendor_user`). Envoyez `deletion_instruction: privacy_erasure` pour les demandes de personnes concernées\_: cela purge chaque gabarit conservé pour cet utilisateur et n'en conserve jamais de nouveau.\n\n**Irréversible\_:** la suppression est définitive et il n'existe aucun endpoint de restauration. Exportez tout ce dont vous avez besoin (par exemple un PDF de décision) avant de l'appeler.\n\n**Effets secondaires\_:** aucun webhook n'est émis pour les suppressions.\n\n**Réponse\_:** `200 OK` une fois la suppression terminée, avec un corps JSON indiquant le `face_retention_outcome`, l'expiration du gabarit conservé et, pour une session KYB, `deleted_child_verifications`. Les versions antérieures de cet endpoint renvoyaient `204 No Content`\_; mettez à jour les clients qui vérifient `204`. Conservez votre `instruction_id` dans votre propre journal d'effacement.\n\n**Idempotence\_:** non idempotent au niveau HTTP\_: le premier appel renvoie `200`\_; le répéter renvoie `404` car la session n'est plus résolue. Après un `503`, la session est toujours présente\_; réessayez la même requête pour terminer sa suppression.\n\n**Authentification\_:** envoyez la clé API de votre application dans l'en-tête `x-api-key`\_; la session doit appartenir à cette application. Les tokens d'accès utilisateur de la Console (`Authorization: Bearer ...`) peuvent également appeler cet endpoint lorsqu'ils disposent de l'autorisation `delete:sessions`. Les échecs d'authentification et d'autorisation renvoient tous deux `403`\_; cette API ne renvoie jamais `401`.\n\n**Limite de débit\_:** quota d'écriture partagé de 300 requêtes/min par clé API sur l'ensemble des endpoints POST/PATCH/DELETE\_; le dépasser renvoie `429`.\n\nPour supprimer en masse des sessions KYC par leur `session_number` numérique, utilisez plutôt `POST /v3/sessions/delete/`.\n\n**Rapports réglementaires déposés\_:** si les données sélectionnées figurent dans un rapport réglementaire finalisé, l'ensemble de la requête est refusé avec `409` et rien n'est supprimé. Le corps utilise `code: in_filed_report` et nomme chaque rapport avec `uuid`, `report_number`, `report_type` et `case_uuid`. Supprimez les rapports, puis réessayez la requête." operationId: delete_v3_session_by_id parameters: - in: path name: sessionId required: true description: >- 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`. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 requestBody: required: false description: >- Optionnel. Omettez entièrement le corps pour suivre la politique de conservation de l'application avec une suppression opérationnelle. content: application/json: schema: type: object properties: retain_face_embeddings: type: boolean nullable: true description: >- 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. example: true face_retention_days: type: integer minimum: 1 maximum: 3650 description: >- 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`. example: 365 face_retention_deadline: type: string format: date-time description: >- Expiration stricte optionnelle pour un modèle conservé. Doit être dans le futur. example: '2027-08-28T00:00:00Z' deletion_instruction: type: string enum: - operational_session_delete - privacy_erasure default: operational_session_delete description: >- 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`). example: operational_session_delete instruction_id: type: string maxLength: 255 description: >- 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. example: dsar-2026-0142 examples: Retain a biometric template: summary: >- Supprimer la session, conserver un modèle sans image pendant 365 jours value: retain_face_embeddings: true face_retention_days: 365 instruction_id: post-approval-cleanup-2026-08 Force deletion on an opted-in application: summary: >- Supprimer l'embedding facial quelle que soit la politique de l'application value: retain_face_embeddings: false Privacy erasure: summary: "Demande de la personne concernée\_: supprimer la session et purger chaque gabarit conservé pour cette personne" value: deletion_instruction: privacy_erasure instruction_id: dsar-2026-0142 responses: '200': description: >- 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. content: application/json: schema: type: object properties: session_id: type: string format: uuid description: La session supprimée. session_number: type: integer nullable: true description: Le numéro de la session supprimée. face_retention_outcome: type: string enum: - retained_with_user - deleted - none - ineligible_no_vendor_user description: >- 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. biometric_template_uuid: type: string format: uuid nullable: true description: >- 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: type: string format: date-time nullable: true description: >- 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: type: integer description: >- 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. examples: Deleted (default): value: session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02 session_number: 1024 face_retention_outcome: deleted biometric_template_uuid: null biometric_template_expires_at: null deleted_child_verifications: 0 Retained with User: value: session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02 session_number: 1024 face_retention_outcome: retained_with_user biometric_template_uuid: 9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b biometric_template_expires_at: '2027-10-09T10:15:00Z' deleted_child_verifications: 0 'Ineligible: no User': summary: Conservation demandée sur une session créée sans vendor_data value: session_id: 7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c session_number: 1031 face_retention_outcome: ineligible_no_vendor_user biometric_template_uuid: null biometric_template_expires_at: null deleted_child_verifications: 0 KYB session: value: session_id: 0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b session_number: 88 face_retention_outcome: none biometric_template_uuid: null biometric_template_expires_at: null deleted_child_verifications: 3 summary: >- Une vérification d'entreprise supprimée avec les trois vérifications créées pour ses personnes clés '400': description: Erreur de validation — rien n'est supprimé. content: application/json: examples: Privacy erasure cannot retain: value: retain_face_embeddings: - Privacy erasure cannot retain biometric templates. No finite retention duration: summary: >- Conservation demandée sans face_retention_days sur la requête ou l'application value: detail: >- A finite biometric-template retention duration is required. '403': description: >- Échec d'authentification ou d'autorisation. Une clé manquante renvoie également `403` ; une clé incorrecte, révoquée ou expirée renvoie `401`. Exception : lorsque le `sessionId` ne correspond à aucune session active, la recherche préalable du propriétaire renvoie `404` en premier, même avec des identifiants manquants ou non valides. content: application/json: schema: type: object properties: detail: type: string examples: Missing or invalid API key: summary: Aucun en-tête x-api-key, ou la clé est invalide value: detail: >- Authentication credentials were not provided or are invalid. Insufficient permission: summary: >- Token utilisateur sans delete:sessions, ou identifiants pour une application qui ne possède pas la session value: detail: You do not have permission to perform this action. '404': description: >- Aucune session KYC ou KYB active avec ce `session_id` n'existe — l'identifiant est inconnu ou la session a déjà été supprimée (répéter une suppression réussie aboutit ici). content: application/json: schema: type: object properties: detail: type: string examples: Not Found: summary: Session inconnue ou déjà supprimée value: detail: Not found. '409': description: >- La session fait partie d'un rapport réglementaire finalisé. Rien n'est supprimé. content: application/json: schema: $ref: '#/components/schemas/InFiledReportError' '429': description: >- Limite de débit d'écriture partagée dépassée (300 requêtes POST/PATCH/DELETE par minute et par clé API). Examinez `Retry-After` et les en-têtes de réponse `X-RateLimit-*` avant de réessayer. content: application/json: schema: type: object properties: detail: type: string examples: Rate limited: summary: Budget d'écriture épuisé value: detail: >- Write request rate limit exceeded. You can make up to 300 requests per minute. '503': description: "La suppression n'a pas pu aboutir car un service de stockage, un stockage biométrique ou un fournisseur de surveillance était indisponible. La session est toujours présente\_; réessayez la même requête jusqu'à ce qu'elle renvoie `200`. Certains de ses fichiers stockés ou son embedding facial peuvent déjà être supprimés, ne vous y fiez donc pas après un `503`. Les nouvelles tentatives convergent vers un seul modèle." content: application/json: schema: type: object properties: detail: type: string examples: Session deletion unavailable: summary: >- Un service de stockage ou un fournisseur de surveillance était indisponible value: detail: >- The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it. Biometric store unavailable: summary: >- Un service de stockage biométrique était indisponible lors de la conservation ou de la suppression définitive d'un gabarit value: detail: >- The biometric-template operation could not finish because an external store is unavailable. The operation is retryable. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl (default policy) source: |- curl -X DELETE \ https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \ -H 'x-api-key: YOUR_API_KEY' - lang: curl label: curl (retain template) source: |- curl -X DELETE \ https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"retain_face_embeddings": true, "face_retention_days": 365}' - lang: curl label: curl (privacy erasure) source: |- curl -X DELETE \ https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.delete( "11111111-2222-3333-4444-555555555555", retain_face_embeddings=True, face_retention_days=365, instruction_id="post-approval-cleanup-2026-08", ) print(result) - lang: javascript label: Node.js source: >- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.sessions.delete("11111111-2222-3333-4444-555555555555", { retain_face_embeddings: true, face_retention_days: 365, instruction_id: "post-approval-cleanup-2026-08", }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Delete(ctx, \"11111111-2222-3333-4444-555555555555\", didit.SessionsDeleteParams{\n\tRetainFaceEmbeddings: didit.Bool(true),\n\tFaceRetentionDays: didit.Int(365),\n\tInstructionID: didit.String(\"post-approval-cleanup-2026-08\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.SessionsDeleteParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().delete("11111111-2222-3333-4444-555555555555", SessionsDeleteParams.builder() .retainFaceEmbeddings(true) .faceRetentionDays(365L) .instructionId("post-approval-cleanup-2026-08") .build()); System.out.println(result); - lang: php label: PHP source: >- sessions->delete('11111111-2222-3333-4444-555555555555', [ 'retain_face_embeddings' => true, 'face_retention_days' => 365, 'instruction_id' => 'post-approval-cleanup-2026-08', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.delete( "11111111-2222-3333-4444-555555555555", retain_face_embeddings: true, face_retention_days: 365, instruction_id: "post-approval-cleanup-2026-08" ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Sessions.DeleteAsync("11111111-2222-3333-4444-555555555555", new SessionsDeleteParams { RetainFaceEmbeddings = true, FaceRetentionDays = 365, InstructionId = "post-approval-cleanup-2026-08", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: InFiledReportError: type: object description: >- La suppression est refusée car les données sélectionnées figurent dans un rapport réglementaire finalisé. Rien n'est supprimé. Supprimez le rapport, puis réessayez la requête. required: - detail - code properties: detail: type: string code: type: string enum: - in_filed_report description: >- Code d'erreur stable pour une suppression bloquée par un rapport réglementaire finalisé. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: >- Rapports qui bloquent la suppression d'une personne, d'une entreprise, d'un dossier ou d'une session. transactions: type: array items: $ref: '#/components/schemas/FiledReportTransaction' description: >- Transactions qui bloquent la suppression d'une transaction, chacune accompagnée des rapports qui la répertorient. FiledRegulatoryReport: type: object description: Un rapport réglementaire finalisé qui empêche la suppression demandée. required: - uuid - report_number - report_type - case_uuid properties: uuid: type: string format: uuid description: UUID du rapport. report_number: type: string description: Numéro de rapport affiché dans la Console (par exemple, SAR-0001). report_type: type: string enum: - SAR - STR - CTR - TTR - UTR - IFT - CBR - TFR description: Type de rapport réglementaire. case_uuid: type: string format: uuid description: Dossier auquel appartient le rapport. FiledReportTransaction: type: object description: >- Une transaction qui ne peut pas être supprimée car un rapport réglementaire finalisé la répertorie. required: - uuid - transaction_id - reports properties: uuid: type: string format: uuid description: UUID de transaction Didit. transaction_id: type: string description: >- L'identifiant de la transaction fourni lors de la création de la transaction. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: Rapports finalisés répertoriant cette transaction. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- 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. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.