Saltar al contenido principal
PATCH
curl

Qué hace este endpoint

Una sesión de verificación se compone de funciones (pasos) individuales: ID/OCR, prueba de vida, coincidencia facial, análisis AML, prueba de domicilio, teléfono, etc. Este endpoint te permite establecer el estado de uno de esos pasos en Approved, Declined o In Review. Usa update-status cuando quieras aprobar, rechazar o reabrir la sesión completa. Usa este endpoint cuando solo quieras registrar una decisión sobre un único paso, por ejemplo, para marcar el paso de coincidencia facial como Declined en tu propio flujo de revisión. Una sesión que ya tiene una decisión la conserva: solo cambia el paso. Si la sesión aún no tiene decisión y su flujo de verificación (workflow) está a la espera de este paso concreto, aplicar la modificación completa el paso, igual que si se hubiera terminado de forma normal. El flujo avanza, se ejecutan los pasos posteriores, y un nodo de estado puede establecer la decisión de la sesión y disparar un webhook status.updated.

Cómo apuntar a un paso con node_id

En los flujos basados en grafos, cada paso tiene un node_id (por ejemplo, feature_ocr_1, feature_liveness_1, feature_aml_1). Puedes encontrarlos en la decisión de la sesión: cada función de una decisión V3 incluye su node_id. En los flujos que no se basan en grafos (de un solo paso), la función subyacente no tiene ID de nodo. Pasa el valor literal default como nodeId para apuntar a ella. Como ningún paso de este tipo de flujo tiene ID de nodo, pasa también feature_type (por ejemplo, LIVENESS, AML o FACE_MATCH) para indicar a qué paso te refieres. Un feature_type desconocido devuelve 400.

Esperar a que la persona termine el flujo

De forma predeterminada, la modificación se aplica de inmediato. Si la persona todavía está recorriendo el flujo, eso cambia un paso de un flujo que sigue en curso; en ese caso, la modificación se registra con forced: true. Establece defer_until_flow_finishes: true para esperar. Mientras la sesión esté en Not Started, In Progress o Resubmitted y la persona no haya terminado, la modificación se guarda como pending_until_flow_finishes. Se aplica cuando la persona termina el flujo, después de que el flujo llegue a su propia decisión. En una sesión cuyo flujo ya terminó, se aplica de inmediato en cualquier caso. Una modificación en espera se cancela en lugar de aplicarse cuando:
  • la persona repite el paso antes de terminar (check_changed),
  • una modificación más reciente sobre el mismo paso la sustituye (replaced),
  • la sesión se cierra sin que el flujo haya terminado: abandonada, expirada o decidida a mitad del flujo (session_closed),
  • la cancelas con Cancel Feature Override (cancelled_by_reviewer).
El campo override de la respuesta te indica qué ocurrió: state es applied o pending_until_flow_finishes, y applied_at se establece una vez aplicada. El campo new_status de nivel superior es el estado guardado del paso, por lo que no cambia mientras la modificación está en espera. Usa List Feature Overrides para ver todas las modificaciones de una sesión y si la persona sigue en el flujo.

Compatibilidad con KYC y KYB

Funciona igual para las sesiones de Verificación de usuario (KYC) y de Verificación de empresas (KYB): Didit resuelve el sessionId en ambos tipos. Los tipos de paso compatibles incluyen ID/OCR, prueba de vida, coincidencia facial, NFC, análisis AML, prueba de domicilio, teléfono, correo electrónico, validación de base de datos, cuestionario y las comprobaciones de registro, documentos y personas clave de KYB.
En las sesiones de API independientes (las creadas mediante las API de verificación independientes, session_type = API) no se pueden cambiar los estados de funciones individuales: el endpoint devuelve 400.

Ejemplos

Qué ocurre después de una actualización

  • Webhook: se dispara un evento data.updated cuando se aplica la modificación, ya sea de inmediato o cuando termina el flujo. No se envía nada mientras está en espera ni cuando se cancela.
  • Actividad: cada modificación se registra en la actividad de la sesión como FEATURE_OVERRIDE_PENDING, FEATURE_OVERRIDE_APPLIED o FEATURE_OVERRIDE_CANCELLED, junto con quien la realizó (clave de API, usuario o el sistema cuando se aplica una modificación en espera). La entrada de la solicitud incluye tu comment como motivo. En el array reviews de la decisión de la sesión, estas entradas aparecen con new_status: null, y la entrada de la solicitud tiene tu motivo en comment.
  • Decisión de la sesión: una sesión que ya tiene una decisión la conserva. Para cambiar la decisión final, invoca update-status por separado.

Permiso

Requiere el privilegio write:sessions, con una clave de API de cliente (x-api-key) o un encabezado de autorización de usuario. Una clave de API con alcance limitado necesita acceso de escritura a las decisiones.

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. 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"

nodeId
string
requerido

ID del nodo del grafo del flujo correspondiente a la función que se va a actualizar (por ejemplo, feature_ocr_1). Usa el valor literal default para flujos que no se basan en grafo (de un solo paso), en los que la función no tiene ID de nodo.

Ejemplo:

"feature_ocr_1"

Cuerpo

application/json
new_status
enum<string>
requerido

Estado de destino para esta función. Debe ser distinto del valor actual.

Opciones disponibles:
Approved,
Declined,
In Review
Ejemplo:

"Approved"

comment
string

Nota opcional en texto libre que se registra en el historial de revisión de la sesión para este cambio de función.

Ejemplo:

"Document manually verified by compliance."

feature_type
enum<string>

Qué tipo de paso se quiere seleccionar. Es obligatorio en los flujos que no son de grafo (nodeId = default), donde los pasos no tienen nodo propio; en los demás casos es opcional. Un valor desconocido devuelve 400.

Opciones disponibles:
ID_VERIFICATION,
OCR,
OCR_BACK,
NFC,
LIVENESS,
FACE,
AGE_ESTIMATION,
AGE_VERIFICATION,
FACE_SEARCH,
FACE_MATCH,
IP_ANALYSIS,
AML,
PHONE,
PHONE_VERIFICATION,
EMAIL,
EMAIL_VERIFICATION,
POA,
PROOF_OF_ADDRESS,
DATABASE_VALIDATION,
DATA_VALIDATION,
QUESTIONNAIRE,
DOCUMENT_AI,
KYB_REGISTRY,
KYB_DOCUMENTS,
KYB_KEY_PEOPLE,
BANK_VERIFICATION,
GEOLOCATION
Ejemplo:

"LIVENESS"

defer_until_flow_finishes
boolean
predeterminado:false

Mientras la persona sigue en el flujo, guarda la anulación como pending_until_flow_finishes y aplícala cuando el flujo termine, en lugar de hacerlo de inmediato. Si se omite o es false, la anulación se aplica de inmediato. En una sesión cuyo flujo ya terminó, se aplica de inmediato en ambos casos.

Ejemplo:

false

Respuesta

Se registró la anulación. new_status es el estado de la comprobación tal como está almacenado: el solicitado una vez aplicada la anulación, o el que no ha cambiado mientras espera a que termine el flujo. override indica qué ocurrió.

session_id
string<uuid>
requerido
node_id
string | null
requerido

El nodo del flujo del paso actualizado, o null para un paso sin nodo (la ruta default en un flujo que no es de grafo).

Ejemplo:

"feature_ocr_1"

feature_type
string
requerido

Nombre del modelo de la función actualizada (p. ej., KYC, Face, FaceMatch, AML, POA).

Ejemplo:

"KYC"

new_status
string
requerido

El estado almacenado de la comprobación: el solicitado una vez aplicada la anulación manual, o el original sin cambios mientras la anulación espera a que termine el flujo.

Ejemplo:

"Approved"

override
object
requerido

Una modificación manual del estado de una comprobación (función) realizada con PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/: qué cambia, si se aplicó o sigue a la espera de que la persona termine el flujo, quién la solicitó y por qué.

Última modificación el 1 de noviembre de 2026