Was ist ein Webhook?

23. Juli 2026 · 6 Min. Lesezeit

Ein Webhook ist eine der einfachsten Ideen der Webentwicklung, begraben unter viel Fachjargon: Statt dass du einen Dienst immer wieder fragst „gibt’s was Neues?“, ruft der Dienst dich an, sobald etwas passiert. Dieser Guide deckt alles ab, was in der Praxis zählt.

Die Definition in einem Satz

Ein Webhook ist ein HTTP-POST-Request, den ein System an eine von dir angegebene URL schickt, in dem Moment, in dem ein Ereignis eintritt. Mehr nicht. Kein spezielles Protokoll, kein SDK, keine Magie – dasselbe HTTP, das auch dein Browser spricht.

Der Name führt in die Irre: Da „hakt“ sich nichts ins Web. Denk an einen Callback fürs Internet, oder wie manche sagen: eine umgekehrte API – nicht du rufst an, sondern der Dienst ruft dich.

Wie es abläuft, Schritt für Schritt

Du hinterlegst eine URL beim sendenden Dienst („Payload URL“, „Webhook-URL“, „Endpoint“). Das ist eine ganz normale HTTPS-Adresse, die dir gehört.
Etwas passiert – eine Bestellung geht ein, ein Build scheitert, eine Zahlung geht durch.
Der Dienst sendet einen HTTP-POST an deine URL, meist mit einem JSON-Body, der das Ereignis beschreibt.
Deine Seite antwortet mit einem Statuscode. 2xx heißt „angekommen“; alles andere löst meist einen Retry aus.

Webhook vs. API: Was ist der Unterschied?

Beide sprechen HTTP, die Richtung ist umgekehrt. Bei einer API stellst du die Anfrage und bekommst eine Antwort. Beim Webhook stellt der Dienst die Anfrage und du antwortest. Deshalb braucht ein Webhook eine öffentlich erreichbare URL, während ein API-Aufruf von überall funktioniert.

In der Praxis ergänzen sie sich: Der Webhook sagt dir, dass eine Bestellung da ist; brauchst du die vollständige Bestellung, rufst du die API.

Webhook vs. Polling: warum Webhooks gewonnen haben

Polling heißt, jede Minute zu fragen: „Was Neues?“ Das funktioniert, ist aber verschwenderisch (99 % der Anfragen antworten „nein“), langsam (bis zu einer Minute Verzögerung) und verbrennt Rate-Limits. Ein Webhook feuert genau einmal, genau dann, wenn es nötig ist, mit null Anfragen dazwischen. Der Kompromiss: Dein Endpoint muss in diesem Moment erreichbar sein – dafür gibt es Retries.

Was steckt in einem Webhook?

Drei Dinge zählen: die Methode (fast immer POST), die Header (Content-Type, oft eine Signatur) und der Body – der Payload. Ein minimales Beispiel:

POST /dein-endpoint HTTP/1.1
Host: api.example.com
Content-Type: application/json
X-Signature: t=1690000000,v1=5257a869e7…

{"event":"order.created","id":"ord_1042","amount":4999,"currency":"EUR"}

Die Payload-Strukturen unterscheiden sich stark zwischen Anbietern – der Payload-Guide zeigt die üblichen Muster und wie man sie liest.

Die vier häufigsten Anfängerfehler

Langsam antworten. Arbeit asynchron erledigen und sofort 2xx zurückgeben – viele Anbieter brechen nach wenigen Sekunden ab.
Duplikate ignorieren. Retries bedeuten, dass dasselbe Ereignis zweimal ankommen kann. Behandle es idempotent.
Dem Absender vertrauen. Wer deine URL kennt, kann posten – Signaturen prüfen.
Falscher Statuscode. 4xx heißt oft „nie wieder versuchen“, 5xx heißt „versuch’s nochmal“ – Statuscode-Guide.

Wie empfange ich einen Webhook ohne Server?

Klassisch bräuchtest du einen öffentlichen HTTPS-Endpoint – Server, Cloud Function, Tunnel. Wenn das Ziel aber schlicht ist, zu wissen, dass etwas passiert ist, reicht ein fertiger Endpoint: Webhooky gibt dir eine persönliche URL, und jeder POST darauf wird zur Push-Benachrichtigung am Handy – mit eigenem Sound pro Ereignistyp. Installieren (Android / iOS), URL kopieren, beim sendenden Dienst einfügen. Das ist das ganze Setup.

Weiterlesen

Hol dir Webhooky

Kostenlos für deine ersten 100 Benachrichtigungen – Endpoint in zwei Minuten eingerichtet.