API para actualizar datos de sesión: corrige KYC y KYB

​

Requisitos comunes

• Autorización: clave de API de cliente (x-api-key estándar o bearer en Authorization) o token de autenticación de usuario.
• Privilegio:
  • KYC y POA: write:sessions
  • Empresa KYB y parte de Personas clave: write:businesses
• Estado de la sesión (solo KYC / POA): debe ser APPROVED, DECLINED, IN_REVIEW o KYC_EXPIRED. Las sesiones que no han llegado a un estado revisable no se pueden modificar. Las actualizaciones de empresas KYB no tienen restricción de estado.
• Debe existir un registro de la función: solo puedes modificar campos KYC si la sesión capturó un KYC, campos POA si capturó un POA y campos de empresa KYB si la sesión tiene una comprobación del registro de empresas.
• Actualizaciones parciales: solo cambian los campos que incluyas. Omite un campo para dejarlo como está. Envía null para eliminar una clave de extra_fields.
• Webhooks: una actualización exitosa dispara data.updated con session_kind: "user" o "business", y el historial de auditoría de la sesión registra qué campos concretos cambiaron y quién los cambió.

​

Actualizar los datos de identidad KYC

​

Campos modificables

​

Ejemplo

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'

​

Actualizar los datos de Prueba de domicilio (POA)

​

Campos modificables

​

Ejemplo

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-poa-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "utility_bill",
    "issuer": "Iberdrola",
    "issue_date": "2026-03-15",
    "name_on_document": "Jane Doe",
    "poa_parsed_address": {
      "street_1": "Calle Mayor 10",
      "city": "Madrid",
      "postal_code": "28013",
      "country": "ES"
    }
  }'

​

Actualizar los datos de empresa de KYB

​

Requisitos

• Permiso: write:businesses (distinto del permiso de KYC / POA).
• El companyUuid de la URL debe pertenecer al sessionId indicado; de lo contrario, recibes un 404.
• No hay restricción por estado de la sesión: los datos de empresa de KYB se pueden corregir en cualquier momento.

​

Campos modificables

​

Ejemplo

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/f7a9c1b2-4e6d.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Corporation Limited",
    "registration_number": "12345678",
    "registry_status": "active",
    "legal_address": "1 Main Street, London EC1A 1AA, United Kingdom",
    "alternative_names": "Acme Ltd, Acme Group"
  }'

​

Omitir a una parte de Personas clave

​

Requisitos

• Permiso: write:businesses.
• El partyUuid de la URL debe pertenecer al sessionId indicado; de lo contrario, recibes un 404.
• No depende de allow_skip. Esa configuración del rol limita lo que el solicitante puede omitir mientras completa la pantalla alojada de Personas clave; este endpoint es la anulación del operador, por lo que funciona incluso en roles que el solicitante no podría haber omitido.

​

Cuerpo

​

Ejemplo

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/parties/0a3f1e2c-7c2f.../" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_skipped": true }'

​

Qué ocurre después de una actualización

• Webhook: se activa data.updated en la sesión, con el session_kind de la sesión en el payload ("user" o "business"). Suscríbete una sola vez a nivel de destino y enruta según session_kind.
• Registro de auditoría: la sesión registra exactamente qué campos cambiaron, los valores anteriores y nuevos y (en las llamadas autenticadas como usuario) el correo electrónico de quien hizo el cambio. Se puede ver en la pestaña Events de la consola.
• Nueva geocodificación de la dirección: en las actualizaciones de KYC y POA que cambian address / poa_address, Didit vuelve a ejecutar la geocodificación en segundo plano. Los fallos se ignoran, de modo que la actualización nunca falla por un problema de geocodificación.
• Nueva evaluación AML: las actualizaciones de KYC que cambian el nombre, la fecha de nacimiento o la nacionalidad pueden volver a disparar el análisis AML si este no había terminado en la sesión. Los resultados aparecen en la decisión de la sesión.

​

Cuándo no usar estos endpoints

• Volver a ejecutar toda la verificación: si el cliente tiene que volver a tomar la foto de su documento de identidad o volver a subir un documento, usa update-status para pasar la sesión a Resubmitted.
• Cambiar campos del perfil de la entidad User o Business: usa PATCH /v3/users/{vendor_data}/ o PATCH /v3/businesses/{vendor_data}/; esos endpoints actualizan datos a nivel de entidad, no a nivel de sesión.
• Editar los datos de Personas clave: no existe una API pública para modificar el nombre, los roles o la propiedad de una parte; esos datos se envían a través del flujo alojado. El único campo modificable es is_skipped (consulta Omitir a una parte de Personas clave).

​

Errores

​

Próximos pasos