Skip to main content
Conecta un receptor HTTPS público en Configuración → Integraciones → Webhooks. Cuando un monitor seleccionado marca una llamada nueva, Zelto envía un evento 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.
  1. Crea los monitores cuyos resultados positivos quieres recibir.
  2. 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.
  3. 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.
  4. Elige Enviar prueba. Procesa webhook.test como se explica abajo y responde con cualquier código 2xx. Puedes probar el destino mientras está pausado.
  5. 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.
La activación no exporta llamadas existentes. Agregar otro monitor conserva la cobertura de las suscripciones que no cambian. Quitar y volver a agregar un monitor, o pausar y reactivar el destino, inicia la cobertura desde la nueva activación. La hora original de la llamada del proveedor puede ser anterior al ingreso en Zelto. Los destinos muestran solo el hostname del receptor; las credenciales, rutas y parámetros de consulta permanecen ocultos. Al editar, deja la URL vacía para conservarla. Generar un nuevo secreto de firma rota el secreto y pausa el destino. Actualiza tu receptor, envía una prueba y vuelve a habilitar los envíos. Cambiar la URL o el secreto cancela las entregas pendientes; prepara tu receptor antes de habilitar los envíos. Una petición HTTP ya iniciada puede llegar después de pausar o editar el destino.

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:
Usa 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:
Verifica la firma y devuelve 2xx para este tipo. No insertes una entrada en el historial del cliente. Las pruebas se solicitan explícitamente desde la pantalla del destino, aparecen con su tipo de evento en el historial y no reservan una coincidencia del monitor.

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:
Lee los encabezados desde tu framework HTTP y pasa el cuerpo UTF-8 original; parsea JSON después de verificarlo. Rechaza verificaciones fallidas con una respuesta que no sea 2xx. Mantén el secreto de firma del lado del servidor.

Guardar una vez, confirmar y reintentar

Después de verificar, distingue por type. 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 payload monitor_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.