Webhooks drehten die API um: Statt zu fragen, werden Apps aufgerufen, wenn etwas passiert

Im Jahr 2007 hatten Websites APIs, doch die Integration bedeutete weiterhin Polling: Eine Anwendung klopfte immer wieder an die Tür einer anderen, um zu fragen, ob etwas Neues passiert sei. Jeff Lindsays Blogbeitrag „Web hooks to revolutionize the web“ plädierte dafür, die Unix-Pipes-Idee auf das Web anzuwenden – einfache Programme, die sich über Ein- und Ausgabe miteinander verketten –, indem Websites Callbacks registrieren konnten, die andere Websites bei Eintritt eines Ereignisses aufrufen würden.

Das Design ist radikal in seiner Kleinheit: Ein Webhook ist ein benutzerdefinierter HTTP-Callback. Man gibt der auslösenden App eine URL; wenn das Ereignis eintritt, sendet sie die Daten per POST an diese. Kein Message-Broker, kein neues Wire-Format, keine neuen Ports oder Zertifikate – nur eine Anfrage über das Web, das ohnehin alle betreiben. Jede Integration ist eins-zu-eins, sodass das Netzwerk ohne zentrale Koordination wächst.

Das Muster verbreitete sich Plattform für Plattform. GitHub, Stripe, Shopify und Slack führten Webhook-Unterstützung ein, und in den 2010er-Jahren konnte eine Integrationsplattform wie Zapier es als den Standardweg beschreiben, auf dem Apps miteinander „sprechen“ – der Push-E-Mail-Moment für Anwendungen, in dem Software aufhörte zu prüfen und begann zu empfangen.

Ruf uns nicht an – wir rufen dich an, über einfaches HTTP

Ein Webhook ist eine URL, sodass jede App einen anbieten kann, ohne neue Infrastruktur

Push schlägt Polling: keine verschwendeten Anfragen und standardmäßig nahezu Echtzeit-Zustellung

Es nutzt einfaches HTTP, sodass Firewalls, Proxys und TLS bereits funktionieren

Eins-zu-eins-Verbindungen wachsen zu einem Netzwerk ohne zentralen Broker zusammen

Der billigste Standard ist derjenige, der keine neue Maschinerie benötigt. Wenn man das neue Muster mit dem ausdrücken kann, was ohnehin alle betreiben – eine URL, ein HTTP-POST –, erledigt sich die Akzeptanz von selbst.

Webhooks entwickelten sich von der Idee eines Außenseiters zum Mindeststandard, und die Einfachheit schuf ihre eigenen Probleme, um die die Branche anschließend standardisierte: Payloads werden heute signiert (Stripe machte HMAC-Signaturen populär), Konsumenten benötigen Wiederholungsversuche und Idempotenz, und Empfänger, die vom Angreifer gelieferte URLs abrufen, wurden zu einem klassischen Vektor für serverseitige Anfragefälschung (Server-Side Request Forgery), den OWASP ausführlich dokumentiert. Was als Blogbeitrag begann, ist heute der Weg, wie Zahlungen bestätigt, Code bereitgestellt und Chat-Apps benachrichtigt werden.