> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Mensajes a clientes en la gestión de casos > En Didit, previsualiza mensajes fijos, solicita información a un contacto verificado y revisa las respuestas del cliente. Abre un caso y elige **Enviar mensaje al cliente**. Elige un destinatario verificado, un idioma y el propósito, y luego selecciona **Vista previa**. La vista previa muestra el remitente, el destinatario, el asunto y el cuerpo del correo electrónico exactos. Elige **Editar** para cambiar la selección o **Enviar** para confirmarla. Una vista previa modificada o expirada debe generarse de nuevo antes del envío. ## Propósitos del mensaje | Propósito | Acción del cliente | Estado del caso | | - | - | - | | Documento de identidad | Subir una fotografía nítida de un documento de identidad | Esperando al usuario | | Prueba de domicilio | Subir un documento reciente que muestre el nombre y la dirección residencial | Esperando al usuario | | Documento de empresa | Subir un documento de registro de la empresa | Esperando al usuario | | Confirmar datos | Enviar un nombre completo y una fecha de nacimiento para que el revisor los evalúe | Esperando al usuario | | Revisión en curso | No se requiere ninguna acción; el correo electrónico no incluye ningún botón de respuesta | Sin cambios | 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: ```text theme={null} GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/options/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/preview/ GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/cancel/ POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/remind/ GET /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/attachment/ ``` Leer el historial y los adjuntos requiere `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.