Ein Webhook ist eine Webadresse, an die ein System eine Nachricht schickt, sobald etwas passiert: Ein Formular wird abgeschickt, eine Zahlung geht ein, ein Termin wird gebucht. Das empfangende System muss dafür nicht ständig nachfragen, es wird gerufen. Genau deshalb sind Webhooks der Startpunkt fast jeder Automatisierung, die sofort reagieren soll. In diesem Beitrag erkläre ich verständlich, wie ein Webhook funktioniert, wie er sich von einer API unterscheidet und worauf du bei Sicherheit und Fehlersuche achten solltest.

Was ist ein Webhook? Die Kurzfassung

Stell dir vor, du wartest auf ein Paket. Du kannst alle zehn Minuten zur Haustür gehen und nachsehen, oder du lässt dich vom Paketboten anklingeln. Ein Webhook ist die Klingel. Das System, in dem etwas passiert, ruft eine Adresse auf, die du vorher festgelegt hast, und übergibt dabei eine kurze Nachricht mit den Details.

Technisch ist das eine ganz normale Webanfrage. Die Adresse ist eine URL, die der Empfänger bereitstellt. Der Absender schickt dorthin meist eine POST-Anfrage, deren Inhalt im Format JSON aufgebaut ist. Mehr steckt nicht dahinter. Wichtig sind drei Bausteine:

  • Das Ereignis: Im Absender passiert etwas, zum Beispiel wird ein Formular abgeschickt, eine Zahlung verbucht oder ein Termin gebucht.
  • Die Adresse: Du hinterlegst im Absender die URL, die benachrichtigt werden soll. Sie ist so etwas wie die Telefonnummer, unter der dich das System erreicht.
  • Die Nachricht: Der Absender schickt die Daten zum Ereignis mit. Fachleute nennen das Payload, also Nutzlast.

Du findest Webhooks auch unter Namen wie HTTP Callback oder umgekehrte API. Gemeint ist immer dasselbe Prinzip: Nicht du fragst, sondern das andere System meldet sich bei dir.

Wo begegnen dir Webhooks? Fast überall, wo Systeme miteinander sprechen. Ein Onlineshop meldet eine neue Bestellung an die Buchhaltung. Ein Buchungstool gibt dem Kalender Bescheid. Ein Zahlungsanbieter bestätigt, dass das Geld da ist. Ein Newsletter-Dienst meldet, dass sich jemand ausgetragen hat. Dahinter steckt immer dasselbe Muster, und wer es einmal verstanden hat, erkennt es in jeder Oberfläche wieder, selbst wenn dort „Benachrichtigung“ oder „Event“ steht.

Polling oder Webhook: Wer fragt, wer meldet

Es gibt zwei Wege, wie ein System erfährt, dass es etwas Neues gibt. Beim Polling fragt dein System in festen Abständen nach: Gibt es neue Einträge? Meistens lautet die Antwort nein, und beim nächsten Durchlauf wird wieder gefragt. Beim Webhook dreht sich das um. Das andere System meldet sich genau dann, wenn etwas passiert ist.

In Make.com siehst du den Unterschied direkt. Ein Szenario mit Zeitplan schaut in dem Intervall nach, das du einstellst. Ein Szenario, das an einem Webhook hängt, startet in dem Moment, in dem die Nachricht ankommt. Bei einer Kontaktanfrage macht das einen spürbaren Unterschied: Die Bestätigung an den Interessenten kann sofort rausgehen, statt erst beim nächsten Durchlauf. Wie Make.com grundsätzlich aufgebaut ist, erkläre ich im Beitrag zu den Make.com Grundlagen.

Polling verursacht außerdem Arbeit ohne Ergebnis: Die meisten Abfragen laufen ins Leere, belasten aber trotzdem beide Systeme. Je kürzer der Abstand, desto mehr davon.

Als Faustregel für die Wahl:

  • Ein Webhook passt, wenn die Reaktion schnell erfolgen soll und der Absender Webhooks anbietet.
  • Polling passt, wenn der Absender keine Webhooks kennt oder eine Verzögerung von einigen Minuten keine Rolle spielt.

Nicht jedes Programm bietet Webhooks an. Dann ist Polling kein Notbehelf, sondern der richtige Weg.

Webhook und API: Wer bestimmt den Zeitpunkt

Webhook und API werden oft gegeneinander ausgespielt, dabei sind sie Partner. Eine API ist eine Schnittstelle, über die du ein System gezielt etwas fragst oder ihm etwas aufträgst. Du entscheidest, wann das passiert. Bei einem Webhook entscheidet der Absender. Du stellst nur die Adresse bereit.

Ein Bild dazu: Die API ist die Speisekarte im Restaurant. Du bestellst, wann du Hunger hast. Der Webhook ist die Nachricht der Küche, dass dein Essen fertig ist.

In der Praxis arbeiten beide zusammen. Der Webhook meldet nur kurz, dass etwas passiert ist, etwa „Bestellung 4711 ist eingegangen“. Alle Einzelheiten holt sich dein Ablauf anschließend über die API. Das hat zwei Vorteile: Die Nachricht bleibt klein, und du bekommst immer den aktuellen Stand statt einer Momentaufnahme, die schon veraltet sein kann. Viele Dienste arbeiten genau so, andere schicken gleich alle Daten mit. Ein Blick in die Dokumentation des Absenders klärt, welcher Fall vorliegt.

Beispiel: Vom Kontaktformular zum Termin

Ein Alltagsbeispiel aus vielen kleinen Betrieben: Jemand füllt das Kontaktformular deiner Website aus. Du willst, dass die Anfrage sofort im Kundensystem steht, eine Bestätigung rausgeht und ein Rückruftermin vorgemerkt wird. Ohne Webhook kopierst du die Daten aus einer Mail von Hand. Mit Webhook läuft es so:

  1. In Make.com ein neues Szenario anlegen und als Start das Modul „Custom webhook“ wählen. Make erzeugt eine eigene URL.
  2. Diese URL im Formular oder im Formular-Dienst als Ziel eintragen. Wie das geht, steht in der Dokumentation des jeweiligen Anbieters. Bei einer individuell gebauten Website kann das Formular die Nachricht auch selbst an die Adresse senden.
  3. Make auf Empfang stellen und eine Testanfrage abschicken. Daran erkennt Make, welche Felder die Nachricht enthält.
  4. Folgemodule ergänzen: Eintrag im Kundensystem, Bestätigungsmail, Kalendereintrag.
  5. Das Szenario aktivieren. Ab jetzt startet es bei jeder Anfrage von selbst.

So könnte die Nachricht aussehen, die dabei bei Make ankommt. Die Daten sind erfunden:

{
  "event": "formular.abgeschickt",
  "id": "a1b2c3d4",
  "name": "Mia Muster",
  "email": "mia@beispiel.de",
  "nachricht": "Bitte um Rückruf am Donnerstag"
}

Das Feld event sagt, was passiert ist. Das Feld id ist eine eindeutige Nummer, die du später brauchst, um Doppelmeldungen zu erkennen. Der Rest sind die Formulardaten. Mehr als diese Felder braucht ein Ablauf selten.

Eine Regel gilt für jeden Empfänger: schnell antworten. Der Absender wartet nach dem Senden nur kurz auf ein Okay, meist wenige Sekunden. Kommt nichts, gilt die Nachricht als nicht zugestellt, und viele Absender schicken sie erneut. Ein Webhook sollte den Eingang deshalb zuerst bestätigen und die eigentliche Arbeit danach erledigen, nicht umgekehrt. Bei Make.com übernimmt das die Plattform. Bei einer selbst programmierten Empfängerseite musst du es selbst einbauen.

Wohin die Daten danach wandern sollten und wie du Dubletten vermeidest, steht im Beitrag zur CRM Integration. Solche Abläufe gehören zu dem, was ich im Bereich KI Automatisierung für kleine Unternehmen aufbaue.

Sicherheit: Wer darf an deine Adresse klopfen

Ein einfacher Webhook ist eine öffentlich erreichbare Adresse. Wer sie kennt, kann ihr Nachrichten schicken, ganz gleich, ob er der echte Absender ist. Deshalb gehören ein paar Schutzmaßnahmen dazu:

  • Adresse geheim halten: Bei einfachen Webhooks ist die URL fast ein Passwort. Poste sie nicht in Screenshots, Chats oder öffentlichen Repositories. Ist sie doch einmal rausgegangen, erzeuge eine neue.
  • Geheimnis mitschicken und prüfen: Viele Absender erlauben einen Schlüssel in der Kopfzeile oder in der Adresse. Dein Ablauf prüft ihn als Erstes und bricht bei einem falschen Wert ab.
  • Signatur prüfen: Größere Dienste wie Zahlungsanbieter signieren ihre Nachrichten. Dein Ablauf rechnet die Signatur nach und verwirft Nachrichten, die nicht passen.
  • Nur HTTPS verwenden: Nur dann sind die Daten unterwegs verschlüsselt.
  • Inhalt prüfen: Fehlen Pflichtfelder oder sind Werte leer, soll der Ablauf stoppen und nicht mit leeren Daten weiterarbeiten.

Ein Punkt wird gern übersehen: Steht die Webhook-Adresse direkt im öffentlichen Quelltext deiner Website, kann jeder sie auslesen. Besser schickt der Server der Website die Nachricht an den Webhook, und der Schlüssel wird dort ergänzt, wo ihn kein Besucher sieht.

In meinem eigenen Ablauf, der neue Blogbeiträge ins Google-Unternehmensprofil stellt, hängt ein Make-Szenario an einem Webhook. Es vergleicht als Erstes einen mitgeschickten Schlüssel und postet erst danach. Wer nur die Adresse kennt, kann damit nichts veröffentlichen.

Dazu kommt der Datenschutz. Ein Formular-Webhook transportiert personenbezogene Daten, etwa Name und Mailadresse. Schicke deshalb nur die Felder, die der Ablauf wirklich braucht, und kläre mit dem Dienst, an den die Daten gehen, den Vertrag zur Auftragsverarbeitung und den Serverstandort.

Testen und Fehler finden, wenn nichts ankommt

Wenn ein Webhook nichts bewirkt, liegt es fast immer an einer von wenigen Ursachen. Die Suche geht schneller, wenn du weißt, wo du hinschauen musst:

  • Die Nachricht kommt nicht an. Die Adresse wurde falsch kopiert, das Szenario ist nicht aktiv, oder der Absender sendet gar nicht. Ein Testdienst, der eine Wegwerf-Adresse bereitstellt und jede eingehende Nachricht anzeigt, zeigt dir in Sekunden, was der Absender wirklich schickt.
  • Die Nachricht kommt an, aber Felder fehlen. Meist wurde die Datenstruktur mit einer Testanfrage erfasst, die anders aussah als echte Anfragen. Schicke eine zweite Testanfrage mit allen Feldern.
  • Nachrichten kommen doppelt. Antwortet der Empfänger zu langsam oder mit einem Fehlercode, versuchen viele Absender es erneut. Speichere die id jeder verarbeiteten Nachricht und überspringe bekannte.
  • Der Absender meldet einen Fehler. Der Statuscode der Antwort verrät die Ursache: 200 bedeutet angenommen, 401 oder 403 eine verweigerte Berechtigung, 404 eine Adresse, die es nicht gibt, und 410 eine Adresse, die bewusst entfernt wurde.

Make.com quittiert den Eingang standardmäßig mit einem kurzen „Accepted“. Das heißt nur: Die Nachricht ist angekommen. Ob dein Ablauf danach alles richtig gemacht hat, siehst du erst im Verlauf des Szenarios. Prüfe deshalb immer beide Stellen.

Den Statuscode 410 kenne ich aus eigener Erfahrung. Bei meinem Blog-Ablauf war einmal ein Szenario gelöscht worden, der Absender zeigte aber weiter auf die alte Adresse und bekam 410 zurück. Der Fehler lag nicht im Ablauf, sondern in der veralteten Adresse. Die Reparatur bestand darin, Szenario und Webhook neu aufzubauen und den Ablauf mit einer echten Meldung zu belegen. Ein Haken im Szenario reicht dafür nicht, erst die ausgeführte Meldung am Ziel zählt.

Zum Mitnehmen, die Reihenfolge für deinen ersten Webhook:

  1. Festlegen, welches Ereignis welchen Ablauf auslösen soll.
  2. Im Empfänger eine Webhook-Adresse anlegen.
  3. Die Adresse im Absender eintragen und mit einem Schlüssel absichern.
  4. Eine Testnachricht senden und prüfen, ob alle Felder ankommen.
  5. Doppelmeldungen und leere Felder abfangen, erst dann den Ablauf aktivieren.

Dein erster Webhook: gemeinsam aufbauen

Lass uns deinen ersten Webhook gemeinsam aufbauen. Schreib mir über das Kontaktformular, welches System bei dir die Anfragen oder Bestellungen sammelt und was danach automatisch passieren soll. Daraus ergibt sich ein erster Ablauf, der zu deinem Betrieb in Trier passt und sich ohne großen Aufwand umsetzen lässt.

DF
Dominique Feld
Webdesigner und SEO-Spezialist aus Trier. Individuelle Websites, die bei Google funktionieren.