Los webhooks cambiaron la API: en lugar de preguntar, las aplicaciones reciben una llamada cuando ocurre algo

En 2007 los sitios web tenían API, pero la integración seguía consistiendo en sondear: una aplicación llamaba una y otra vez a la puerta de otra para preguntar si había ocurrido algo nuevo. La entrada de blog de Jeff Lindsay 'Web hooks to revolutionize the web' abogaba por aplicar al web la idea de las tuberías de Unix —programas simples que se encadenan mediante entrada y salida— permitiendo que los sitios registraran callbacks que otros sitios llamarían cuando ocurriera un evento.

El diseño es radical por su pequeñez: un webhook es un callback HTTP definido por el usuario. Le das a la aplicación de origen una URL; cuando se dispara el evento, te envía los datos mediante POST. Sin broker de mensajes, sin nuevo formato de transmisión, sin nuevos puertos ni certificados: solo una petición sobre la web que todos ya ejecutan. Cada integración es uno a uno, así que la red se multiplica sin ningún coordinador central.

El patrón se extendió plataforma por plataforma. GitHub, Stripe, Shopify y Slack lanzaron soporte de webhooks, y para la década de 2010 una plataforma de integración como Zapier podía describirlo como la forma predeterminada en que las aplicaciones 'hablan' entre sí: el momento del correo push para las aplicaciones, cuando el software dejó de comprobar y empezó a recibir.

No nos llames: nosotros te llamamos, sobre HTTP simple

Un webhook es una URL, así que cualquier aplicación puede ofrecer uno sin nueva infraestructura

El envío supera al sondeo: sin peticiones desperdiciadas y entrega casi en tiempo real por defecto

Se apoya en HTTP simple, así que los firewalls, los proxies y TLS ya funcionan

Las conexiones uno a uno se multiplican en una red sin un broker central

El estándar más barato es el que no necesita nueva maquinaria. Si puedes expresar el nuevo patrón con lo que todos ya ejecutan —una URL, un POST HTTP—, la adopción se cuida sola.

Los webhooks pasaron de ser la idea de un outsider a un requisito básico, y la simplicidad creó sus propios problemas en torno a los cuales la industria luego se estandarizó: ahora las cargas útiles se firman (Stripe popularizó las firmas HMAC), los consumidores necesitan reintentos e idempotencia, y los receptores que obtienen URL proporcionadas por atacantes se convirtieron en un vector clásico de falsificación de petición del lado del servidor que OWASP documenta en detalle. Lo que comenzó como una entrada de blog es ahora cómo confirman los pagos, se despliega el código y las aplicaciones de chat envían avisos.