monitor.matched. Tu receptor puede guardar el resultado
en tu base de datos, CRM o historial del cliente. Zelto envía el evento a tu
endpoint HTTP; tu sistema controla la escritura en la base.
Configurar un destino
Los propietarios y administradores gestionan los destinos y su historial.- Crea los monitores cuyos resultados positivos quieres recibir.
- Elige Agregar destino, ingresa un nombre y una URL HTTPS pública en el puerto 443, y selecciona al menos un monitor (hasta 100). Seleccionar monitores actuales (hasta 100) selecciona hasta 100 de la lista actual; los monitores futuros no se suscriben automáticamente.
- Guarda el destino. Comienza Pausado. Copia el secreto de firma generado, que se muestra una sola vez, y guárdalo de forma segura en el receptor.
- Elige Enviar prueba. Procesa
webhook.testcomo se explica abajo y responde con cualquier código 2xx. Puedes probar el destino mientras está pausado. - Elige Habilitar envíos en los pasos de configuración del destino, o habilítalos desde Editar destino. Solo son elegibles las llamadas ingresadas después de la activación. Consulta Última prueba y el historial para confirmar la entrega; el programador normalmente recoge pendientes dentro de un minuto.
Eventos
monitor.matched
Se registra un evento por el primer resultado positivo de cada llamada y monitor
mientras exista un destino elegible. Reprocesar o cambiar la versión del monitor
no crea otro evento para esa pareja. Un resultado antes negativo puede producir
su primer evento al volverse positivo. Los resultados negativos, no evaluados,
fallidos, de vista previa, benchmarks y experimentos aislados no emiten eventos.
Una corrección posterior no retracta una detección ya entregada.
Es un evento posterior al análisis, no una detección de keywords en vivo. Incluye
los valores tipados y explicaciones existentes del monitor. Una lista de keywords
detectadas solo está disponible si tu monitor realmente extrae esa lista.
Ejemplo sintético:
data.conversation.externalId, el ID de llamada que enviaste originalmente,
para unir el evento con tus registros. endUserId es un ID opaco opcional de la
persona que puedes enviar al cargar llamadas.
Cualquiera puede ser null si no se proporcionó. company_id identifica una empresa
o acreedor y no debe usarse como ID de la persona llamada.
occurredAt indica cuándo se registró el evento; evaluatedAt identifica el
resultado capturado. startedAt puede ser null. overallScore es un número o
null; items[].value conserva su tipo JSON original. El snapshot no cambia en
los reintentos. No se incluyen transcripciones completas, grabaciones, teléfonos,
prompts ni metadatos libres de la llamada. Los valores del monitor pueden contener
información del cliente: guárdalos con los mismos controles que sus resultados.
Los monitores que solo tienen filtros pueden devolver items vacío: pasar sus
filtros es el resultado positivo. No se realiza una extracción adicional de keywords.
webhook.test
Las pruebas no contienen datos reales de llamadas o clientes:
Verificar la firma
Cada petición contiene:
El mensaje firmado es
timestamp + "." + rawBody. Verifica el cuerpo original
sin procesar, antes de parsear JSON o cambiar espacios. El timestamp y la firma
cambian en cada intento; el cuerpo y el ID del evento se mantienen. Este verificador
Node.js rechaza firmas de más de cinco minutos de antigüedad:
Guardar una vez, confirmar y reintentar
Después de verificar, distingue portype. Para monitor.matched, identifica a
la persona usando el ID externo de la llamada o el endUserId proporcionado y
guarda el ID del evento y la entrada del historial en una misma transacción.
Impón una restricción única sobre el ID del evento. Devuelve 2xx solo después de
guardar de forma durable, o de poner el trabajo en una cola durable de tu sistema.
Si el ID ya fue procesado, devuelve 2xx sin insertar otra entrada.
La entrega es al menos una vez, sin garantía de orden. Una respuesta puede
perderse después del commit: los reintentos automáticos y manuales pueden repetir
un evento. No dedupliques por nombre de monitor ni supongas que solo un monitor
puede dar positivo en una llamada.
Zelto permite hasta seis intentos automáticos. Las esperas base entre intentos
son 5, 10, 20, 40 y 80 minutos, más hasta 30 segundos aleatorios. Se reintentan
respuestas distintas de 2xx, errores de red y tiempos de espera agotados; un
Retry-After válido en 429 o 503 pospone el siguiente intento si indica una fecha
posterior. Los destinos inválidos o privados fallan sin intentos repetidos.
DNS tiene un tiempo de espera de 5 segundos y HTTP de 15 segundos. No se siguen
redirecciones. El programador puede agregar una demora breve al intento vencido.
Las entregas se ejecutan separadas del análisis de llamadas.
El Historial de entregas muestra las últimas 50 entregas, sus estados,
intentos, resúmenes acotados de errores y hasta 100 resultados recientes de
intentos. Las detecciones muestran el monitor y un enlace a la llamada mientras
se conserve su contenido, con su referencia externa cuando exista. La búsqueda
y los filtros de estado se aplican a estas últimas 50 entregas. El ID del evento
y el registro de intentos están en Detalles técnicos e intentos. Las entregas
pendientes se actualizan cada 15 segundos mientras la página está visible; las
actualizaciones se pausan al editar o consultar un secreto de una sola
visualización. Puedes usar Actualizar para consultar manualmente.
Usa Reenviar para una entrega
terminal mientras se conserve su contenido y el destino esté habilitado (las
pruebas también pueden reenviarse con el destino pausado). Se usa la configuración
actual, el mismo ID y cuerpo, y un nuevo presupuesto de intentos automáticos.
Una entrega activa o con un lease vigente no se puede reiniciar; espera su
finalización o el vencimiento del lease. No hay replay masivo de llamadas históricas.
El contenido se conserva por un máximo de 30 días desde el ingreso de la llamada,
o menos según la política efectiva de retención de la organización. Borrar la
llamada, el monitor o la organización elimina el contenido relacionado. Un
contenido vencido no se puede reenviar. Se conserva un identificador mínimo del
evento mientras existan la llamada y el monitor para no emitir la misma primera
coincidencia después de limpiar el contenido.
Otras funciones de webhooks
Estos webhooks por llamada son distintos del webhook semanal de reportes de monitores, cuyo payloadmonitor_report.weekly y deduplicación por ID de entrega no cambian. Los webhooks
de integraciones de voz envían llamadas a Zelto;
esta integración envía detecciones desde Zelto a tu sistema.
