Saltar al contenido principal
PATCH
curl

Compatibilidad con KYC y KYB

Este endpoint funciona exactamente igual para las sesiones de Verificación de usuario (KYC) y de Verificación de empresas (KYB). Didit busca el session_id en ambos tipos de sesión, y la validación de las transiciones de estado es la misma para los dos (se aplica el mismo enum de estados a ambos). La respuesta solo incluye el session_id. Consulta session_kind en Obtener sesión cuando tu lógica posterior necesite actuar según el tipo.

Transiciones permitidas

Puedes cambiar una sesión a Approved, Declined o Resubmitted. Cualquier otro new_status, incluido In Review, devuelve 400. El estado actual de la sesión debe ser Approved, Declined, In Review, Kyc Expired, Abandoned o Resubmitted; de lo contrario, la API devuelve 400. Asignar Approved o Declined a una sesión que ya tiene ese estado no tiene efecto: la API devuelve 200 y no cambia nada, no dispara ningún webhook ni envía ningún correo electrónico. Asignar Resubmitted a una sesión que ya está en Resubmitted devuelve 400 (The new status is the same as the current status.). Un reenvío cuyos nodes_to_resubmit contienen solo funciones que se ejecutan únicamente en el backend (AML, DATABASE_VALIDATION, IP_ANALYSIS) se ejecuta automáticamente y devuelve la sesión a un estado con una decisión tomada sin interacción del usuario. Repetir un reenvío de este tipo en menos de 30 segundos devuelve 429 Too Many Requests con un encabezado Retry-After, ya que una repetición inmediata no puede producir un resultado distinto. No reenvíes automáticamente la sesión desde un controlador de webhook cada vez que recibas un estado In Review: primero revisa el hallazgo o cambia los datos subyacentes.

Previsualiza primero el correo electrónico

Con send_email: true, Approved y Declined envían a la persona el correo electrónico con su decisión, y Resubmitted le envía un enlace nuevo con los motivos. Puedes ver ese correo electrónico antes de cambiar nada:
  1. Llama a Previsualizar correo de decisión para Approved o Declined, o a Previsualizar correo de reenvío para Resubmitted.
  2. Comprueba el subject y el html renderizados, el recipient y will_be_sent / not_sent_reason.
  3. Llama a este endpoint con el mismo new_status (y, en el caso de un reenvío, los mismos nodes_to_resubmit), send_email: true, email_address con el valor de recipient, el email_language que previsualizaste y email_preview_token con el valor de preview_token.
Ninguna de las dos previsualizaciones modifica la sesión ni envía nada. Después, la actualización envía exactamente el correo electrónico que previsualizaste. El comprobante expira a los 15 minutos. Si el destinatario, el idioma, el estado de la sesión, el remitente o el correo electrónico cambiaron desde la previsualización, la actualización devuelve 409 antes de que se modifique nada; vuelve a previsualizar y confirma con el nuevo comprobante. Enviar email_preview_token sin send_email: true devuelve 400. El paso de previsualización es opcional: las integraciones existentes pueden seguir llamando a este endpoint sin él.

Ejemplos

Permiso

Requiere el privilegio write:sessions. El mismo privilegio cubre ambos tipos.

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 de la sesión de verificación que se va a actualizar. Acepta ID de sesión tanto de usuario (KYC) como de empresa (KYB): el servicio resuelve el ID en ambos tipos de sesión.

Ejemplo:

"11111111-2222-3333-4444-555555555555"

Cuerpo

application/json
new_status
enum<string>
requerido

Estado de destino. Approved y Declined registran una decisión manual definitiva (cada una también puede revertir la otra). Resubmitted borra los pasos seleccionados y devuelve la sesión al usuario. Cualquier otro valor devuelve 400.

Opciones disponibles:
Approved,
Declined,
Resubmitted
Ejemplo:

"Approved"

comment
string

Motivo del cambio en texto libre, que se guarda en el historial de revisiones de la sesión y se devuelve en el array reviews de Obtener decisión. Por ejemplo, Duplicated user.

Ejemplo:

"All checks passed manual review"

nodes_to_resubmit
object[]

Pasos del flujo que el usuario debe repetir. Solo se tienen en cuenta cuando new_status es Resubmitted. Con Approved/Declined las entradas se siguen validando contra el esquema (un valor de feature no válido devuelve 400), pero las entradas válidas se ignoran a efectos de su significado. Si se omite, el servidor selecciona automáticamente los intentos existentes de OCR, Liveness, Face Match, POA, Phone, Email, AML, Database Validation y Questionnaire cuyo estado es Declined, In Review, Not Finished o Expired (los intentos de NFC, análisis de IP, estimación de edad, búsqueda facial y documentos KYB nunca se seleccionan automáticamente; los intentos faciales que no son de coincidencia facial se seleccionan como LIVENESS). Las funciones que el usuario nunca intentó (sin ningún intento registrado) NO se seleccionan, por lo que una sesión sin intentos devuelve 400 ("No features found that need resubmission") aunque no se haya aprobado nada; en ese caso, envía nodes_to_resubmit de forma explícita. Los pasos se ejecutan en el orden del grafo del flujo, sin importar el orden en que los envíes. KYB_REGISTRY, KYB_KEY_PEOPLE y el alias KYB se rechazan con 400: esas comprobaciones principales se recalculan a partir de sus sesiones KYC hijas.

send_email
boolean
predeterminado:false

Indica si se envía un correo electrónico al usuario sobre el cambio. Requiere email_address. Con Approved/Declined el usuario recibe un aviso de estado; con Resubmitted el correo incluye el enlace de verificación y los motivos de reenvío de cada paso.

Ejemplo:

false

email_address
string<email>

Destinatario del correo electrónico de notificación. Obligatorio cuando send_email es true: si lo omites, se devuelve 400.

Ejemplo:

"user@example.com"

email_language
string
predeterminado:en

Idioma del correo electrónico de notificación. El esquema acepta cualquier cadena; los códigos no admitidos pasan a inglés (en) sin avisar.

Ejemplo:

"en"

email_preview_token
string
write-only

Comprobante opcional de Vista previa del correo de decisión (para Approved y Declined) o de Vista previa del correo de reenvío (para Resubmitted): su preview_token. Solo es válido con send_email: true; sin este, la solicitud devuelve 400. El destinatario, el idioma, el estado de la sesión, el remitente y el correo (y, en un reenvío, los pasos seleccionados) deben seguir coincidiendo con la vista previa, y el comprobante caduca a los 15 minutos. De lo contrario, la solicitud devuelve 409 antes de que cambie la sesión o se envíe ningún correo. Las integraciones existentes pueden omitir este campo.

Required string length: 1 - 512

Respuesta

Estado actualizado. La respuesta solo contiene el session_id; obtén la sesión actualizada con Obtener decisión. El webhook status.updated se dispara una vez que se confirma el cambio. Repetir Approved o Declined devuelve el mismo cuerpo y no cambia nada.

session_id
string<uuid>

UUID de la sesión actualizada.

Última modificación el 1 de noviembre de 2026