Define una acción HTTP y el chatbot puede llamar a tu CRM, tu sistema de tickets, tu consulta de inventario. Los webhooks publican eventos hacia la automatización que tu cliente ya usa. Cada llamada registra lo que salió y lo que regresó.
Un chatbot que solo responde es media función. La otra mitad es el momento en que crea el ticket, envía el prospecto o marca el pedido, sin que tu equipo lo teclee.
Crea una acción en tres pasos guiados: cuándo debe usarla el agente, qué necesita recopilar y a dónde envía el resultado — webhooks, tus APIs o un ticket — con una lista de verificación antes de salir en vivo.
Un chatbot que responde es útil. Un chatbot que crea el ticket de soporte, califica el prospecto en el CRM o consulta el inventario antes de responder es una función por la que tu cliente firma el contrato. Las acciones son las llamadas HTTP. Los webhooks son los eventos que la automatización de tu cliente ya escucha. El inspector te muestra cada llamada y cada respuesta para que depurar sea rápido.
Cualquier endpoint HTTP puede ser una acción, sin necesidad de un conector específico de proveedor.
Webhooks de salida para eventos que la automatización de tu cliente ya maneja.
El inspector de ejecuciones muestra el payload y la respuesta completos de cada llamada.
El visitante pidió abrir un ticket. El chatbot lo prometió. El chatbot no lo hizo. El visitante está molesto; la agencia se entera. Las acciones cierran esa brecha.
Cada cliente tiene un CRM distinto, una mesa de ayuda distinta, un sistema de inventario distinto. Escribir un conector para cada uno no escala.
El webhook salió. El receptor devolvió un 500. El chatbot siguió adelante. Sin un inspector, te enteras en la siguiente revisión de cuenta, cuando las métricas no cuadran.
Define un nombre, un endpoint, un encabezado de autenticación, la forma del payload. El chatbot ya puede llamarlo. La mayoría de las API internas usan HTTP: cada una de ellas se convierte en una acción.
Make, n8n, Zapier o un endpoint personalizado. El chatbot publica el evento; el receptor hace lo que sea que haga. Firma opcional para los receptores que verifican firmas.
El chatbot ejecutó la acción. El receptor respondió. Ambos visibles en el inspector. Cuando algo falla, el inspector es el primer lugar al que acudes.
Identifica qué necesita hacer el chatbot más allá de responder: crear un ticket, enviar un prospecto, consultar el inventario.
Define la acción o el webhook y pruébalo en el inspector.
Deja que el chatbot lo use. Observa las ejecuciones.
Cuando algo falla, el inspector te dice qué salió y qué regresó.
Con qué frecuencia el chatbot realmente hace llamadas externas, no solo responde.
Qué integraciones son inestables. Corrige la causa, no el síntoma.
Código de respuesta del receptor por evento. 200 significa entregado; el resto significa investigar.
Chatbots de ventas que crean el registro en el CRM después de calificar al visitante.
Chatbots de soporte que abren el ticket en Zendesk, Freshdesk o Help Scout antes de transferir.
Chatbots operativos que consultan inventario, estado o precios contra una API interna antes de responder.
Las acciones están delimitadas por cliente: las acciones de un cliente no pueden alcanzar los endpoints de otro.
La firma de webhooks es opcional, pero recomendada para receptores que verifican firmas.
El inspector muestra cada llamada, pero solo dentro del contexto del cliente y de la agencia.
Sí: si la API habla HTTP, el chatbot puede llamarla. Tú defines el endpoint, la autenticación y la forma de la carga, y el chatbot la usa como cualquier otra herramienta.
No la necesitas. El webhook es la integración: Make, Zapier y n8n escuchan webhooks de forma nativa. Nosotros enviamos el evento; su automatización lo recibe.
El inspector muestra la solicitud y la respuesta. Depuras desde la misma pantalla, corriges la acción o el receptor, y la siguiente ejecución usa la versión corregida.
Cuéntanos qué quieres poner en marcha y te mostraremos las piezas de la plataforma que te llevan ahí.