Ya explicamos en qué es un webhook en automatización que un webhook es un aviso automático que un sistema envía a otro cuando ocurre algo relevante, sin necesidad de que nadie pregunte. Lo que no siempre queda claro en esa conversación es que un webhook tiene una dirección: puede entrar hacia tu empresa o puede salir desde tu empresa hacia fuera, y esa dirección cambia por completo quién es responsable de qué cuando algo falla. Entender esta distinción es especialmente relevante cuando se diseña una arquitectura de automatización con varios sistemas y un agente de IA en el medio.
Qué es un webhook entrante
Un webhook entrante es el aviso que un sistema externo envía hacia tu empresa cuando algo ocurre en ese sistema externo. Por ejemplo: un cliente completa un pago en tu pasarela de pagos, y esa pasarela envía automáticamente un aviso a tu sistema —o a tu agente de IA— para informar de que el pago se ha completado. Desde el punto de vista de tu empresa, ese webhook "entra": alguien de fuera te está avisando de algo que ha pasado en su sistema.
En este caso, tu empresa es quien recibe la información y quien decide qué hacer con ella: activar el envío de una confirmación, actualizar el estado de un pedido, disparar el proceso de facturación. Tu sistema necesita tener una "puerta" preparada para recibir estos avisos —normalmente una dirección web específica a la que el sistema externo envía la información— y saber verificar que el aviso es legítimo antes de actuar sobre él.
Qué es un webhook saliente
Un webhook saliente es exactamente lo contrario: es el aviso que tu propia empresa envía hacia un sistema externo cuando algo ocurre en tu operación. Por ejemplo: un pedido cambia de estado en tu sistema de gestión, y ese sistema envía automáticamente un aviso a la herramienta de marketing para que dispare un correo de seguimiento, o a un panel de un socio comercial para que actualice su información en tiempo real.
Aquí los papeles se invierten: tu empresa es quien informa, y el sistema externo es quien recibe y decide qué hacer con esa información. La responsabilidad de que el aviso llegue correctamente, con los datos adecuados y en el momento oportuno, recae sobre quien lo envía, es decir, sobre tu empresa o sobre el agente de IA que gestiona ese proceso en tu nombre.
Por qué esta distinción importa en un proyecto de automatización
La diferencia entre entrante y saliente no es un matiz técnico irrelevante: determina dónde está el punto de fallo y quién tiene que solucionarlo. Si un webhook entrante no llega —porque el sistema externo tiene un problema, o porque cambió su formato sin avisar—, el fallo está fuera de tu control directo, y lo máximo que puedes hacer es tener un plan de contingencia, como consultar periódicamente el estado por si el aviso se perdió. Si un webhook saliente falla —porque tu sistema tuvo un error momentáneo, o porque el sistema destino estaba caído en ese instante—, la responsabilidad de detectarlo y reintentarlo es tuya, y un buen diseño de automatización debe incluir reintentos automáticos y alertas cuando un envío falla de forma persistente.
Cuando un agente de IA gestiona un proceso de principio a fin, normalmente maneja ambas direcciones a la vez: recibe webhooks entrantes de varios sistemas para saber qué está pasando, y genera webhooks salientes hacia otros sistemas para comunicar lo que ha decidido o ejecutado. Diseñar bien esa arquitectura implica pensar en los dos sentidos por separado, no solo en si "hay webhooks" de forma genérica.
¿Qué pasa si un webhook saliente no llega a su destino?
Es una de las situaciones que más conviene anticipar en el diseño de una automatización, porque si no se gestiona bien puede generar inconsistencias silenciosas entre sistemas: uno cree que ya avisó al otro, y el otro nunca se enteró de nada. Un webhook saliente bien diseñado incluye reintentos automáticos con espera creciente entre cada intento, un registro de qué avisos se han enviado correctamente y cuáles no, y una alerta a una persona responsable cuando los reintentos se agotan sin éxito. Sin este tipo de control, un fallo puntual de red o un momento de caída del sistema destino puede traducirse en un pedido que nunca se marca como pagado en otra plataforma, o en un cliente que nunca recibe el correo de confirmación que debería haberse disparado automáticamente.
¿Cómo sé si necesito webhooks entrantes, salientes o ambos?
Depende de la dirección en la que fluye la información relevante para el proceso que quieres automatizar, y en la práctica casi ningún proceso de negocio con cierta complejidad usa solo una dirección. Un ejemplo habitual sería una empresa que automatiza la gestión de pedidos: necesita webhooks entrantes desde su pasarela de pagos y desde su transportista para saber cuándo se ha cobrado un pedido y cuándo se ha entregado, y necesita webhooks salientes hacia su herramienta de email marketing y hacia su sistema de contabilidad para informar de esos mismos eventos una vez procesados. La forma más fiable de identificar qué necesitas es dibujar el proceso completo, marcar en qué punto entra información de fuera y en qué punto tu empresa tiene que avisar a otro sistema, y a partir de ahí decidir qué conexiones se hacen mediante webhooks entrantes y cuáles mediante salientes.
Cómo verificar la seguridad en cada dirección
La forma de proteger un webhook entrante y uno saliente también es distinta, precisamente porque el riesgo está en lados opuestos. Para un webhook entrante, la prioridad es verificar que el aviso viene realmente de quien dice venir: la mayoría de proveedores serios incluyen una firma digital en cada aviso que tu sistema puede comprobar antes de actuar, y cualquier automatización que reciba webhooks entrantes debería rechazar de forma automática los avisos que no superen esa verificación, en lugar de asumir que todo lo que llega a esa dirección es legítimo. Para un webhook saliente, la prioridad cambia: hay que asegurarse de que la información que se envía hacia fuera no incluye datos más sensibles de los estrictamente necesarios para que el sistema destino haga su trabajo, y de que el canal de envío está cifrado, para evitar que esa información pueda ser interceptada en tránsito. Tratar ambas direcciones con el mismo nivel de atención en seguridad, y no solo la que resulta más visible, es parte del trabajo de diseño de cualquier automatización que dependa de webhooks.
Preguntas que conviene hacer antes de automatizar con webhooks en ambas direcciones
- Para los webhooks entrantes: ¿cómo verificamos que el aviso viene realmente de quien dice venir, y no de un tercero malicioso?
- Para los webhooks salientes: ¿qué pasa si el sistema destino está caído en el momento del envío? ¿Se reintenta automáticamente?
- ¿Existe un registro centralizado de todos los webhooks, entrantes y salientes, para poder auditar qué pasó si algo falla?
- ¿Quién es responsable de mantener actualizada cada conexión si uno de los sistemas cambia su formato de datos?
Estas preguntas encajan en la revisión más amplia que conviene hacer antes de contratar cualquier proyecto de automatización, recogida en qué preguntar antes de contratar un proveedor de IA.
Conclusión
Un webhook entrante y uno saliente resuelven el mismo problema —avisar automáticamente de que algo ha pasado— pero desde direcciones opuestas, y esa dirección determina de qué lado está la responsabilidad cuando algo falla. Un proyecto de automatización bien diseñado no se limita a preguntar si "hay webhooks", sino que identifica con precisión qué avisos entran, cuáles salen, y qué mecanismo de control existe en cada dirección para que ningún aviso se pierda sin que nadie se entere.
En MG Solutions diseñamos estas conexiones teniendo en cuenta ambas direcciones desde el primer boceto de la automatización, no como un detalle técnico que se resuelve sobre la marcha. Si tu empresa necesita conectar varios sistemas mediante un agente de IA y quieres hacerlo con garantías, pide un diagnóstico gratuito.