Cómo funciona un webhook
Red Hat (documentación consultada el 04/09/2026) lo define como una comunicación ligera, basada en eventos, que envía datos entre aplicaciones de forma automática a través de HTTP. El funcionamiento tiene tres pasos.
Primero, tu aplicación registra en el sistema emisor una URL propia (la «dirección» del webhook) y elige qué eventos quiere recibir: pago aprobado, pedido creado, mensaje entrante, formulario enviado. Segundo, cuando ese evento ocurre, el sistema emisor envía una solicitud HTTP, normalmente de tipo POST, a esa URL con los datos del evento en el cuerpo del mensaje. Tercero, tu aplicación recibe la solicitud, la valida y ejecuta lo que corresponda: actualizar el pedido, enviar una confirmación, crear un registro en el CRM.
La alternativa tradicional es el sondeo o polling: tu aplicación consulta al otro sistema cada minuto para ver si hay novedades. El sondeo consume recursos, genera carga innecesaria y siempre llega tarde. El webhook invierte la lógica: el que tiene la información la envía cuando cambia.
Webhook y API no son lo mismo
Es la confusión más frecuente. Una API es un conjunto de puntos de acceso que tu aplicación llama cuando necesita algo: consultar un stock, crear un cliente, cobrar una tarjeta. La iniciativa es tuya y la comunicación es de ida y vuelta. Un webhook es el camino inverso: el sistema externo toma la iniciativa y te envía datos cuando ocurre algo. Por eso Red Hat los describe como complementarios y no como sustitutos; en la práctica, casi toda integración seria usa ambos. Con la API creas un cobro; con el webhook te enteras de que el cliente lo pagó.
Un ejemplo concreto: tu tienda usa la API de la pasarela para generar un enlace de pago y lo envía por WhatsApp. El cliente paga a las once de la noche. La pasarela dispara un webhook a tu sistema, que marca el pedido como pagado y notifica al almacén, sin que nadie esté mirando un panel.
Ejemplos de uso en una empresa
Los webhooks están detrás de la mayoría de automatizaciones que las empresas dan por sentadas.
Pagos
Todas las pasarelas de pago en Perú notifican por webhook el resultado de una transacción: aprobada, rechazada, reembolsada. Es lo que permite emitir el comprobante y despachar sin revisar manualmente la cuenta.
Ecommerce y pedidos
Cuando un pedido se crea, cambia de estado o se cancela, la plataforma avisa al ERP, al sistema de facturación o al operador logístico; es una de las integraciones clave de una tienda online. En un portal mayorista, el webhook que avisa de cada cambio de stock desde el ERP es lo que evita vender lo que ya no hay.
Mensajería
La API de WhatsApp Business entrega los mensajes entrantes mediante webhooks. Sin ellos, un chatbot o un CRM no podría responder en tiempo real.
Formularios y leads
Un formulario de tu web dispara un webhook que crea el contacto en el CRM, asigna un vendedor y envía un correo de bienvenida. Es la base de la automatización comercial que describimos en automatizar procesos tecnológicos.
Indicadores y alertas
Un sistema puede enviar un webhook cuando una métrica cruza un umbral, y ese aviso alimenta un data warehouse y su tablero, o notifica a un responsable, en lugar de esperar al reporte del lunes.
Operaciones técnicas
En desarrollo de software, un cambio en el repositorio dispara mediante webhook las pruebas y el despliegue automático. Es el mismo principio aplicado a la infraestructura.
Seguridad y buenas prácticas
Un webhook es una puerta de entrada a tu sistema, así que hay que protegerla. Las prácticas mínimas son cuatro. Verificar la firma: la mayoría de emisores incluyen una clave secreta o una firma en la cabecera de la solicitud para que compruebes que el mensaje viene de quien dice venir; Red Hat menciona además la autenticación mutua y el cifrado de la URL como capas adicionales. Usar HTTPS siempre. Diseñar para la repetición: los sistemas emisores pueden reenviar un mismo evento si no reciben confirmación, así que tu aplicación debe reconocer duplicados y no procesar dos veces el mismo pago. Y responder rápido: confirma la recepción de inmediato y procesa después, para que el emisor no lo marque como fallido.
Registra además todo lo que llega. Cuando un pedido «no se actualizó», el historial de webhooks recibidos es lo primero que se revisa.
Cuándo un webhook no es la solución
Si necesitas consultar datos bajo demanda (el saldo de un cliente cuando abre su cuenta), lo tuyo es una API. Si el sistema origen no ofrece webhooks, tendrás que sondear o buscar una capa intermedia. Y si el proceso involucra pantallas de sistemas antiguos sin API ni webhooks, la alternativa suele ser la automatización robótica de procesos (RPA), que imita a un usuario sobre la pantalla.
Qué hacer ahora
Haz un inventario de los avisos que hoy dependen de que alguien revise un panel: pagos, pedidos, mensajes, formularios. Cada uno es un webhook que probablemente ya existe en la herramienta que usas y que nadie configuró. Si quieres que conectemos tus sistemas para que se avisen entre sí sin intervención manual, escríbenos: en Impulsa Studio integramos pasarelas, ERP, CRM y mensajería con webhooks y API en proyectos a medida.


