Webhooks oder Polling: Datenänderungen passend übertragen

Ein Datensatz wird in System A freigegeben. System B soll darauf reagieren. Bei einem Webhook sendet System A eine Ereignismeldung an eine dafür eingerichtete Adresse Ihres Systems. Beim Polling fragt Ihr System in vereinbarten Abständen bei System A nach. Beide Verfahren können einen anschließenden API-Aufruf auslösen, um Daten abzuholen oder weiterzuverarbeiten.

Eine Ereignismeldung muss nicht den vollständigen neuen Datensatz enthalten. Sie kann nur auf ein betroffenes Objekt hinweisen. Prüfen Sie daher, ob die Meldung die benötigten Angaben mitliefert oder ob die Anwendung sie gesondert lesen muss. Die technische Bezeichnung Webhook beantwortet diese Frage nicht.

Polling kann den gesamten relevanten Bestand, Änderungen seit einem gespeicherten Stand oder einzelne Objekte abfragen. Welcher Weg verfügbar ist, bestimmt die API. Ein Abfrageprozess, der nur die erste Ergebnisseite liest, kann Datensätze übersehen. Ein Prozess, der nach jedem Neustart alles erneut verarbeitet, braucht eine passende Wiederholungsregel.

Im ersten Gespräch genügt die fachliche Aufgabe: „Ein freigegebener Vorgang soll im nächsten Arbeitsgang sichtbar sein.“ Daraus wird die erforderliche Aktualität abgeleitet. Ein pauschaler Wunsch nach Echtzeit ist weniger hilfreich als die Frage, wie lange Ihre Mitarbeitenden oder Kunden sinnvoll auf das Ergebnis warten können.

Die Webhook-Adresse erhält eine Anfrage von außen. Sie prüft zunächst den vorgesehenen Absendernachweis, das Format und den Ereignistyp. Nur benötigte und gültige Meldungen gelangen in die vereinbarte Verarbeitung. Ein öffentlich erreichbarer Endpunkt soll nicht beliebige Anfragen ungeprüft wie einen betrieblichen Auftrag behandeln.

Die GitHub-Dokumentation zur Signaturprüfung zeigt, wie ein gemeinsames Geheimnis den Absender und die Unverändertheit einer Meldung prüfbar macht. Das konkrete Verfahren richtet sich nach dem Anbieter. HTTPS und gültige Zertifikate schützen zusätzlich die Übertragung; sie ersetzen die inhaltliche Prüfung der Meldung nicht.

Viele Anbieter erwarten eine schnelle Antwort. Die GitHub-Empfehlungen für Webhooks nennen unter anderem einen begrenzten Antwortzeitraum. Längere Arbeit kann getrennt über eine Warteschlange laufen. Entscheidend ist dann, dass die Meldung vor der Erfolgsbestätigung zuverlässig zur späteren Verarbeitung übernommen wurde. Eine Antwort und ein nur flüchtiger Arbeitsspeicherzustand reichen bei einem anschließenden Prozessabbruch nicht.

Dokumentieren Sie drei getrennte Ergebnisse: Meldung abgelehnt, Meldung angenommen und Verarbeitung abgeschlossen. Wenn das Zielsystem später eine Änderung verweigert, darf die Empfangsbestätigung dieses Problem nicht verdecken. Die verantwortliche Person muss den offen gebliebenen Vorgang finden und einen vorgesehenen nächsten Schritt ausführen können.

Prüfen Sie, ob und wie lange der Anbieter gescheiterte Zustellungen wiederholt. GitHub stellt fehlgeschlagene Webhooks nicht automatisch erneut zu; seine Dokumentation beschreibt manuelle und programmierte Wege. Stripe dokumentiert dagegen automatische Wiederholungen. Ein pauschales „Webhooks versuchen es später noch einmal“ ist deshalb keine belastbare Betriebsaussage.

Für Ihre Verbindung braucht es eine erkennbare Lücke: War die Empfangsadresse nicht erreichbar, ist eine Warteschlange stehen geblieben oder hat das Ziel die Verarbeitung abgelehnt? Diese Fälle unterscheiden sich. Ein grüner Status des Webservers beweist nicht, dass alle gemeldeten Vorgänge im Ziel angekommen sind.

Ein gezielter periodischer Abgleich kann ergänzen, wenn die API ihn unterstützt. Er überprüft zum Beispiel, ob freigegebene Quellaufträge die erwartete Zielzuordnung besitzen. Das ist eine eigene Funktion mit Zugriffsrechten und Regeln. Ein zusätzlicher Timer allein stellt fehlende Daten nicht wieder her.

Vereinbaren Sie, wer eine Störung erhält, welche Vorgänge sicher erneut versucht werden dürfen und welche zunächst fachlich geklärt werden müssen. Eine Übersichtskennung, letzter erfolgreicher Verarbeitungsschritt und verständlicher Fehlergrund helfen. Vertrauliche Nutzdaten sollten dafür nur im tatsächlich erforderlichen Umfang zugänglich werden.

Ein fiktiver Servicebetrieb möchte freigegebene Aufträge in eine Planungsansicht übertragen. Die Vorbereitung betrachtet zunächst einen Auftrag mit synthetischen Angaben. Das ist ein redaktionelles Beispiel, kein Ergebnis einer Ruhrstack-Integration. Die folgenden Prüfungen lassen sich unabhängig vom gewählten Verfahren konkret vereinbaren.

1. Normalfall: Ein freigegebener Auftrag erscheint mit den vereinbarten Daten und einer eindeutigen Zuordnung im Ziel.
2. Wiederholung: Dieselbe Meldung oder Abfrage wird erneut verarbeitet; die vereinbarte Wirkung bleibt ohne zusätzlichen Auftrag erhalten.
3. Verspätung: Ein älterer Hinweis trifft nach einer neueren Änderung ein; er überschreibt keine bereits maßgebliche Information entgegen der festgelegten Regel.
4. Unterbrechung: Der Prozess wird an einer vereinbarten Stelle angehalten und startet anschließend mit nachvollziehbar offenen Vorgängen wieder.
5. Abgewiesene Verarbeitung: Eine fehlende Pflichtangabe führt zu einer auffindbaren Meldung und dem vorgesehenen Bearbeitungsweg.
6. Bestandsabgleich: Eine absichtlich ausgelassene Übertragung wird durch den vereinbarten Abgleich erkannt, sofern dieser zum Umfang gehört.

Halten Sie neben dem Ergebnis auch fest, welcher Teil tatsächlich geprüft wurde. Ein nachgestellter Netzwerkausfall beweist nicht automatisch alle Eigenschaften des produktiven Anbieters. Die Teststrecke ergänzt dessen dokumentierte Zustell- und Abfrageregeln. Nach der Einbindung wird der vereinbarte Ablauf erneut kontrolliert.

Die übergreifende Planung beschreibt API-Schnittstellen planen. Auf der Leistungsseite Entwicklung erläutert Ruhrstack die Arbeit an Systemverbindungen und deren Fehlerverhalten. Für ein erstes Gespräch helfen Systeme, benötigter Auslöser und ein Satz zur zulässigen Verzögerung. Daraus wird ein passender Prüf- und Entwicklungsumfang.