Primeros pasos
Integración / SDKs
Verificación de usuarios
Verificación de empresas
Monitorización de transacciones
Registro de cambiosPropósitos del mensaje
Actualmente, la subida de documentos admite imágenes JPEG, PNG y WebP de hasta 5 MB.
Solo aparecen los propósitos aplicables a la persona objeto del caso.
Actualmente, las plantillas de correo electrónico para clientes están disponibles en inglés, español y portugués.
La consola usa el mismo campo de correo electrónico y el mismo selector de idioma que el reenvío de sesiones.
Destinatarios verificados y plantillas fijas
Un destinatario debe haber completado la verificación de correo electrónico en una sesión que pertenezca al sujeto del caso y a la aplicación. Una dirección importada o editada en un perfil de usuario no cuenta como verificada. Si no existe ningún contacto verificado, el editor de mensajes lo indica y el envío permanece deshabilitado. Los revisores no pueden introducir texto de correo electrónico, enlaces, direcciones de remitente ni destinatarios arbitrarios. El correo electrónico usa la imagen de marca existente de Didit o de marca blanca. Un remitente personalizado requiere que el dominio de correo electrónico configurado esté verificado. Todas las plantillas informan al destinatario de que el correo electrónico no le pedirá contraseñas, códigos de verificación ni pagos. El reenvío de sesiones sigue siendo una acción independiente para repetir comprobaciones de verificación. Su vista previa muestra el correo electrónico de reenvío que se enviará y las comprobaciones seleccionadas.Entrega y respuestas
El historial de mensajes distingue entre los resultados de entrega en cola, enviando, enviado, simulado y desconocido. Un correo electrónico simulado no se envía. Un resultado desconocido significa que el proveedor podría haber aceptado el correo electrónico; el sistema no lo vuelve a enviar automáticamente. Reintentar una solicitud confirmada usa el mismo ID de solicitud para evitar entregas duplicadas. Una solicitud que requiere acción tiene un enlace de respuesta seguro válido durante siete días. Cancelar la solicitud o resolver el caso invalida ese enlace, también después de reabrir el caso. La página del cliente no revela hallazgos privados del caso ni otros registros de origen. Una respuesta presentada aparece en Customer messages como evidencia pendiente de revisión. El caso vuelve a Abierto y cualquier resolución pendiente existente debe revisarse de nuevo. Las respuestas no pueden reemplazar una respuesta anterior, aprobar la verificación original, sobrescribir la identidad de un cliente ni contribuir a un resultado de fraude. Eliminar la verificación de origen o el caso elimina sus solicitudes al cliente y la evidencia que se haya subido.Flujo de trabajo de la API
Todos los endpoints de la consola están acotados a una organización, una aplicación y un caso:read:cases.
Redactar, previsualizar, confirmar, cancelar y enviar recordatorios requiere write:cases.
La confirmación debe incluir los mismos contact_id, purpose y language, además de los request_id, expires_at y preview_token devueltos por la vista previa.
El comprobante de confirmación expira a los 15 minutos, con independencia del plazo de respuesta del cliente.
Un recordatorio vuelve a enviar el mismo correo electrónico al mismo destinatario verificado, como máximo una vez por solicitud cada 24 horas.
No cambia nada más: la solicitud mantiene su plazo y el caso mantiene su estado.
La respuesta devuelve la solicitud, reminded_at, el propio delivery_status del recordatorio (SENT, SIMULATED o UNKNOWN) y next_reminder_at.
Una solicitud que el cliente ya no tiene que responder devuelve 409 con code case_request_not_waiting y un reason: answered, cancelled, expired, closed, not_actionable, not_delivered o contact_unavailable.
Un segundo recordatorio dentro de las 24 horas devuelve 429 con code case_request_reminder_too_soon, una marca de tiempo retry_at y un encabezado Retry-After.
Mientras una resolución está pendiente de aprobación, un recordatorio devuelve 400.
El endpoint del cliente es GET o POST /v3/case-requests/{request_uuid}/ con su encabezado X-Case-Request-Token específico de la solicitud.
El enlace de respuesta lleva esa credencial en su fragmento; la página elimina el fragmento al abrirse.
El token da acceso únicamente a esa solicitud.