Saltar al contenido principal
DELETE

​
Compatibilidad con KYC y KYB

Funciona tanto con sesiones de Verificación de usuario (KYC) como de Verificación de empresas (KYB). El session_id se busca en ambos tipos de sesión y el comportamiento de eliminación es el mismo para ambos. La retención de la plantilla biométrica solo se aplica a las sesiones KYC, porque solo las sesiones KYC contienen un embedding facial.

​
Comportamiento

  • La sesión se elimina junto con todos los intentos de verificación que contiene, incluidos los resultados sustituidos por un reenvío: su decisión, sus datos extraídos, los registros de las funciones asociadas (verificaciones de identidad, consultas a registros, documentos, AML, análisis de IP, etc.), sus revisiones y su registro de actividad, y todos sus archivos almacenados.
  • Al eliminar una sesión de Verificación de empresas (KYB) también se eliminan, de forma recursiva, las verificaciones que creó para sus personas clave (KYC) y sus propietarios corporativos (KYB). La respuesta indica cuántas se eliminaron en deleted_child_verifications. Una verificación a la que solo está vinculada, como un KYC aprobado ya existente que reutilizó, no se elimina.
  • Los datos de firma electrónica también se eliminan: los documentos para firmar y sus archivos Word originales, los PDF firmados, los PDF de evidencias, las imágenes de las firmas y el valor de cada campo. Sus rutas de descarga devuelven 404.
  • La sesión desaparece de inmediato de las respuestas de listado y de decisión, y las URL de archivos multimedia emitidas antes de la llamada dejan de funcionar.
  • Las entregas de webhook que seguían en cola para la sesión, y sus reintentos, se descartan.
  • La monitorización AML continua y la monitorización de registros KYB iniciadas por las verificaciones eliminadas se detienen.
  • La eliminación es permanente e irreversible. No existe ningún endpoint de restauración, así que exporta todo lo que necesites, como el PDF de una decisión, antes de invocar este endpoint.
  • La respuesta es 200 OK, se envía cuando la eliminación ha terminado e incluye un cuerpo JSON que indica qué ocurrió con los datos biométricos faciales de la sesión. Consulta Migración si tu cliente todavía espera 204.

​
Datos en un informe regulatorio finalizado

Si la sesión forma parte de un caso con un informe regulatorio finalizado, la solicitud devuelve 409 y no se elimina nada. La respuesta usa code: in_filed_report e identifica cada informe:
Elimina cada informe con Eliminar informe y luego repite la eliminación. Eliminar el informe no elimina la sesión: la sesión se conserva hasta que vuelvas a llamar a este endpoint.

​
Datos biométricos faciales: eliminar o conservar

Cada sesión de KYC con una selfie de prueba de vida incluye un embedding facial que permite la Búsqueda facial 1:N y la detección de duplicados. De forma predeterminada, ese embedding se elimina junto con la sesión (face_retention_policy: delete_with_session), de modo que una persona cuya sesión eliminaste puede verificarse de nuevo sin que se la marque como duplicada. Las aplicaciones que necesitan que la detección de duplicados se mantenga tras eliminar una sesión pueden activar la conservación de plantillas biométricas. En ese caso, Didit elimina la sesión y todos sus datos como siempre, y conserva una plantilla biométrica facial sin imágenes, gestionada por separado y vinculada al Usuario de la sesión.
Una plantilla biométrica conservada es un dato biométrico. No es anónima, no es temporal y no se elimina con la sesión. Se conserva hasta su fecha de caducidad programada, un plazo anterior que imponga la ley aplicable, la eliminación del Usuario, una solicitud de supresión por privacidad o una purga explícita. Activa la conservación solo cuando tu instrucción como responsable del tratamiento y tu aviso de privacidad la contemplen.
Qué contiene y qué no contiene una plantilla conservada: La conservación se configura en tres niveles, del más general al más específico:
  1. Política de la aplicación en Business Console → App Settings → Data retention o mediante PATCH /v3/webhook/ (face_retention_policy, face_retention_days). Consulta Retención de datos.
  2. Anulación por solicitud con retain_face_embeddings en este endpoint y en Eliminar sesiones en lote.
  3. Clase de instrucción con deletion_instruction. Una instrucción privacy_erasure siempre prevalece: purga todas las plantillas conservadas de ese Usuario y nunca conserva una nueva.

​
Cuerpo de la solicitud

Todos los campos son opcionales. Omite el cuerpo para seguir la política de la aplicación.

​
Respuesta

La respuesta confirma que Didit aceptó y aplicó tu instrucción de eliminación. No es un certificado de supresión: guarda el instruction_id en tu propio registro de supresiones para poder correlacionarlo más adelante con el registro de auditoría.

​
Duración de la conservación y caducidad

Cada plantilla conservada tiene un expires_at finito. Didit lo fija en el primero de estos valores:
  1. face_retention_days de la solicitud, o el face_retention_days de la aplicación cuando la solicitud lo omite;
  2. el plazo general de retención de datos de la aplicación, cuando hay uno configurado;
  3. face_retention_deadline de la solicitud, cuando se proporciona.
Una solicitud que conservaría una plantilla sin ninguna duración finita se rechaza con 400 y no se elimina nada. Las plantillas conservadas no pueden durar más allá de lo primero que ocurra entre la instrucción aplicable del cliente, el fin de la finalidad, la caducidad configurada, la instrucción de supresión del interesado o el plazo legal para datos biométricos. Eres responsable de elegir una duración que cumpla las leyes aplicables a tus usuarios; elige una más corta siempre que una norma aplicable lo exija.

​
Supresión por privacidad

Envía deletion_instruction: "privacy_erasure" cuando atiendas una solicitud de un titular de los datos. Didit purga todas las plantillas biométricas conservadas vinculadas al Usuario de la sesión y, después, elimina la sesión y su embedding. La política de retención de la aplicación no puede anular una instrucción de supresión por privacidad, y retain_face_embeddings: true se rechaza con 400. Eliminar el Usuario con Batch Delete Users también purga sus plantillas conservadas.

​
Qué no se ve afectado

Eliminar una sesión no elimina estos elementos por ti. Si atiendes una solicitud de derecho de supresión, gestiónalos por separado.
  • Las entradas de la lista de bloqueo creadas a partir de la sesión (de rostro o de documento) se mantienen. Elimínalas de la lista de bloqueo. Una entrada de rostro en la lista de bloqueo conserva su propia entrada biométrica, independiente de cualquier plantilla conservada.
  • Los tokens para compartir ya emitidos para la sesión no se revocan, pero ya no queda nada que puedan importar: una operación de importación con uno de ellos devuelve 400 con {"share_token": ["Original session does not exist."]}.
  • Los webhooks ya entregados para la sesión no se ven afectados. Las entregas que aún están en cola, y sus reintentos, se descartan. No se emite ningún webhook por la propia eliminación.
  • Los créditos ya consumidos por la verificación no se reembolsan.
  • Las copias firmadas ya enviadas por correo a un firmante por un paso de firma electrónica están en el buzón del firmante y no se ven afectadas.
  • La entidad principal (Usuario o Empresa) no se elimina. Para ello, usa Delete Users o Delete Businesses. Si el retrato de perfil del Usuario procedía de la sesión eliminada, el retrato se elimina.
  • Una plantilla biométrica conservada (solo si activaste esta opción) se mantiene hasta que caduca o la purgas. Púrgala con la API de plantillas biométricas, eliminando el Usuario o repitiendo la eliminación de otra sesión del mismo Usuario con deletion_instruction: "privacy_erasure".

​
Ejemplos

Respuesta en una aplicación que no ha activado la retención:

​
Errores

Con 400 no se elimina nada. Con 503 la sesión sigue existiendo: repite la misma solicitud hasta que devuelva 200. Es posible que algunos de sus archivos almacenados o su embedding facial ya se hayan eliminado, así que no dependas de ellos después de un 503.

​
Permiso

Requiere delete:sessions. El mismo permiso cubre tanto las sesiones de verificación de usuarios (KYC) como las de verificación de empresas (KYB), además de la anulación de la retención.

​
Eliminación por lotes

Para operaciones masivas sobre sesiones KYC, usa POST /v3/sessions/delete/. Acepta los mismos campos de retención y de instrucción. En la propia solicitud se eliminan hasta 20 sesiones coincidentes, con un resultado por sesión; si hay más, se ejecutan como un trabajo de eliminación. Consulta Batch Delete Sessions.

​
Migración de respuestas 204

Hasta esta versión, el endpoint devolvía 204 No Content. Ahora devuelve 200 OK con el cuerpo JSON documentado más arriba, para que cada eliminación informe de su face_retention_outcome. Actualiza los clientes que comprueban 204. El comportamiento predeterminado no cambia: las aplicaciones existentes se mantienen en delete_with_session y ninguna migración activa la retención en tu nombre. Actívala de forma explícita en la consola o mediante PATCH /v3/webhook/.

​
Relacionado

Autorizaciones

​
x-api-key
string
header
requerido

La clave de API de tu aplicación, que encontrarás en Developers -> API keys en la Business Console. La clave principal tiene acceso completo. Una clave con nombre puede tener un alcance limitado: ninguno, lectura o escritura por recurso, limitada a algunos flujos o a sesiones aprobadas, a una lista de direcciones IP y a una fecha de caducidad. 401 significa que la clave es incorrecta, se revocó o expiró; 403 significa que no se envió ninguna clave, que la clave no tiene acceso a este recurso o acción, o que la solicitud provino de una dirección fuera de su lista de IP; 404 en una ruta de sesión significa que la sesión está fuera de los flujos o estados de la clave. Una clave sin acceso a contenido multimedia recibe las URL de imágenes, videos y PDF como null, y una clave sin permiso de escritura en sesiones recibe los enlaces y tokens de sesión como null. Consulta https://docs.didit.me/console/api-keys.

Parámetros de ruta

​
sessionId
string<uuid>
requerido

UUID (session_id) de la sesión de Verificación de usuarios (KYC) o Verificación de empresas (KYB) que se va a eliminar, tal como se devolvió al crear la sesión. Debe ser un UUID canónico con guiones: un valor que no sea un UUID no coincide con la ruta y devuelve 404.

Ejemplo:

"11111111-2222-3333-4444-555555555555"

Cuerpo

application/json

Opcional. Omite el cuerpo por completo para seguir la política de retención de la aplicación con una eliminación operativa.

​
retain_face_embeddings
boolean | null

Anula la face_retention_policy de la aplicación para esta eliminación. true conserva una plantilla biométrica facial sin imágenes vinculada al usuario de la sesión después de eliminar la sesión; false elimina el embedding facial junto con la sesión; omítelo o usa null para seguir la política de la aplicación. Se ignora en las sesiones KYB y en las sesiones sin embedding facial.

Ejemplo:

true

​
face_retention_days
integer

Duración de retención finita, en días, de una plantilla conservada. Es obligatoria cuando se conserva una plantilla, salvo que la aplicación ya defina face_retention_days. El expires_at de la plantilla es el más temprano entre esta duración, el periodo general de retención de datos de la aplicación y face_retention_deadline.

Rango requerido: 1 <= x <= 3650
Ejemplo:

365

​
face_retention_deadline
string<date-time>

Caducidad estricta opcional para una plantilla retenida. Debe ser una fecha futura.

Ejemplo:

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

​
deletion_instruction
enum<string>
predeterminado:operational_session_delete

El tipo de instrucción que das. operational_session_delete elimina la sesión y conserva una plantilla solo cuando la política o retain_face_embeddings lo indican. privacy_erasure purga todas las plantillas biométricas conservadas vinculadas al usuario de la sesión antes de eliminar la sesión, la política de la aplicación no puede anularla y no se puede combinar con retain_face_embeddings: true (400).

Opciones disponibles:
operational_session_delete,
privacy_erasure
Ejemplo:

"operational_session_delete"

​
instruction_id
string

Tu referencia permanente para esta instrucción de eliminación (por ejemplo, el ID de un ticket de supresión). Se registra en el registro de auditoría y en cualquier plantilla conservada. Didit la genera si se omite.

Maximum string length: 255
Ejemplo:

"dsar-2026-0142"

Respuesta

Sesión eliminada. El cuerpo indica qué ocurrió con los datos biométricos faciales de la sesión y, en una sesión KYB, cuántas de las verificaciones que creó se eliminaron junto con ella.

​
session_id
string<uuid>

La sesión eliminada.

​
session_number
integer | null

El número de la sesión eliminada.

​
face_retention_outcome
enum<string>

Qué ocurrió con los datos biométricos faciales de la sesión. deleted: el embedding facial se eliminó junto con la sesión (valor predeterminado). retained_with_user: la sesión se elimina y se conserva una plantilla biométrica sin imágenes vinculada al User; consulta biometric_template_uuid. none: la sesión no tenía embedding facial (por ejemplo, una sesión KYB o una sesión KYC sin selfie de prueba de vida). ineligible_no_vendor_user: se solicitó la retención, pero la sesión no tiene ningún User vinculado, por lo que el embedding se eliminó junto con la sesión. Este endpoint nunca informa de un fallo del almacén biométrico a través de este campo: devuelve 503 y la sesión no se elimina.

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

ID de la plantilla biométrica conservada cuando face_retention_outcome es retained_with_user; null en caso contrario. Gestiónala a través de /v3/biometric-templates/{template_uuid}/.

​
biometric_template_expires_at
string<date-time> | null

Fecha y hora en que se elimina la plantilla biométrica conservada, cuando face_retention_outcome es retained_with_user; null cuando no se conserva ninguna plantilla.

​
deleted_child_verifications
integer

En una sesión de Verificación de empresas (KYB): cuántas de las verificaciones que creó (las sesiones KYC de sus personas clave y las sesiones KYB de sus propietarios corporativos, de forma recursiva) se eliminaron con ella. Siempre 0 en una sesión KYC.

Última modificación el 1 de noviembre de 2026