Webhooks viraram a API de cabeça para baixo: em vez de perguntar, os apps são chamados quando algo acontece

Em 2007, os sites tinham APIs, mas a integração ainda significava polling: uma aplicação batia na porta da outra repetidamente para perguntar se algo novo tinha acontecido. O post de blog de Jeff Lindsay, 'Web hooks to revolutionize the web', defendia a ideia dos pipes do Unix aplicada à web — programas simples encadeados por entrada e saída — ao permitir que sites registrassem callbacks que outros sites chamariam quando um evento ocorresse.

O design é radical na sua pequenez: um webhook é um callback HTTP definido pelo usuário. Você entrega ao app de origem uma URL; quando o evento dispara, ele faz um POST dos dados para você. Sem broker de mensagens, sem novo formato de transmissão, sem novas portas ou certificados — apenas uma requisição pela web que todo mundo já roda. Cada integração é um-para-um, então a rede se multiplica sem nenhum coordenador central.

O padrão se espalhou plataforma por plataforma. GitHub, Stripe, Shopify e Slack lançaram suporte a webhooks, e nos anos 2010 uma plataforma de integração como o Zapier podia descrevê-lo como a forma padrão de os apps 'falarem' entre si — o momento do e-mail push para as aplicações, quando o software parou de verificar e começou a receber.

Não ligue para nós — nós ligamos para você, por HTTP simples

Um webhook é uma URL, então qualquer app pode oferecer um sem nova infraestrutura

Push vence o polling: sem requisições desperdiçadas e entrega quase em tempo real por padrão

Roda sobre HTTP simples, então firewalls, proxies e TLS já funcionam

Conexões um-para-um se multiplicam em uma rede sem um broker central

O padrão mais barato é o que não precisa de nova maquinaria. Se você consegue expressar o novo padrão no que todo mundo já roda — uma URL, um POST HTTP —, a adoção cuida de si mesma.

Os webhooks passaram de ideia de outsider a requisito básico, e a simplicidade criou seus próprios problemas em torno dos quais a indústria depois se padronizou: os payloads agora são assinados (a Stripe popularizou as assinaturas HMAC), os consumidores precisam de retentativas e idempotência, e os receptores que buscam URLs fornecidas por atacantes se tornaram um vetor clássico de falsificação de requisição do lado do servidor que a OWASP documenta em detalhes. O que começou como um post de blog agora é como pagamentos confirmam, códigos fazem deploy e apps de chat notificam.