Webhook vs. Polling: Wann du welches Muster nutzt (mit Entscheidungshilfe)

Warum die Frage wichtig ist

Fast jede Automatisierung startet mit derselben Entscheidung: Wie bekomme ich Änderungen aus einem System zuverlässig in ein anderes?

Beispiel aus dem Alltag:

Ein Kunde erstellt ein Ticket im System.
Eine Rechnung ist verfügbar.
Ein Payment ist eingegangen.

Du willst das Ereignis schnell mitbekommen, aber du willst nicht jeden Tag Debugging betreiben. Genau dafür sind Webhooks und Polling da - und beide haben klare Stärken und typische Fallen.

Zur Übersicht: Workflows: Automatisierung

Ziel dieses Artikels

Du bekommst eine praktische Entscheidungshilfe:

Wann ist ein Webhook sinnvoll (und wann nicht)?
Wann ist Polling die bessere Wahl?
Wie baust du beide Varianten so, dass sie stabil und sicher laufen?

Kurzfazit (TL;DR)

Webhook: Ideal für Events in (nahezu) Echtzeit, wenn der Anbieter das gut unterstützt. Du brauchst aber sauberes Security- und Retry-Design.
Polling: Ideal, wenn es keine Webhooks gibt, du Kontrolle willst oder du sowieso in Batches arbeitest. Wichtig sind Delta-Sync, Backoff und Limits.
In der Praxis ist die beste Lösung oft: Webhook + regelmäßiges Polling als "Reconciliation" (Abgleich), damit nichts verloren geht.

Grundlagen: Was ist Polling, was ist ein Webhook?

Polling

Polling heißt: Du fragst in einem Intervall beim System nach, ob es etwas Neues gibt.

Beispiel: Alle 10 Minuten GET /invoices?since=...
Vorteil: Du kontrollierst den Takt und kannst sauber drosseln.
Nachteil: Du fragst oft "umsonst", wenn es nichts Neues gibt.

Webhook

Webhook heißt: Das System ruft dich aktiv auf, wenn ein Ereignis passiert.

Beispiel: "invoice.created" wird an deine Endpoint-URL geschickt.
Vorteil: Sehr schnell, sehr effizient, wenn es gut umgesetzt ist.
Nachteil: Du brauchst einen öffentlich erreichbaren Endpoint und musst Requests verifizieren, deduplizieren und robust verarbeiten.

Entscheidungsmatrix: Wann nutze ich was?

Webhook ist meist besser, wenn

du schnelle Reaktionszeit willst (Minuten/Sekunden statt "irgendwann").
du nur wenige Events erwartest, aber sie direkt verarbeitet werden sollen.
der Anbieter Signaturen/Event-IDs/Retry-Mechanismen sauber anbietet.
du eine stabile Infrastruktur für eingehende Requests hast.

Polling ist meist besser, wenn

es keine Webhooks gibt oder sie unzuverlässig sind.
du ohnehin batch-orientiert arbeitest (z.B. Monatsabschluss, wöchentliche Reports).
du Rate Limits und Kosten besser kontrollieren willst.
du den Sync lieber deterministisch "nachziehst" (z.B. nachts).

Faustregel für Solo-Freelancer

Admin-/Backoffice-Prozesse (Buchhaltung, Exporte, Reportings) sind oft Polling/Batches.
Reaktive Prozesse (Incident, Status-Update, Lead kommt rein) sind oft Webhook-first.

Webhooks robust bauen (ohne Bauchgefühl)

1) Verifiziere den Webhook (Security-Default)

Wenn du Webhooks annimmst, musst du davon ausgehen, dass auch andere Leute deinen Endpoint "anpingen". Minimum:

Signaturprüfung (HMAC oder vergleichbar, abhängig vom Anbieter).
Ein Secret pro Endpoint, sicher gespeichert (Environment Variable).
Kein "Security by Obscurity" (lange URL ist kein Schutz).

Zusätzlich sinnvoll:

Rate Limiting (auf Infrastruktur-Ebene, wenn möglich).
Logs ohne sensible Daten (keine Tokens, keine kompletten Payloads, wenn personenbezogene Daten drin sind).

Wenn du das einmal sauber als Muster bauen willst (Signaturen, Replay-Schutz, Logging): Webhook-Security in der Praxis

2) Antworte schnell, verarbeite asynchron

Viele Webhook-Provider erwarten eine schnelle 2xx-Antwort. Wenn du im Request teure Arbeit machst (API-Calls, Datenbank, PDF-Downloads), werden Webhooks häufiger gedroppt oder erneut zugestellt.

Robustes Muster:

Request verifizieren
Event minimal speichern (oder in eine Queue legen)
Sofort 200 antworten
Verarbeitung im Hintergrund

3) Dedupliziere Events (Idempotenz)

Webhooks können doppelt kommen. Nicht "vielleicht" - sondern irgendwann garantiert.

Mach es dir leicht:

Wenn es eine Event-ID gibt: speichere sie und verarbeite jede ID nur einmal.
Wenn es keine gibt: baue einen stabilen Key (z.B. type + objectId + createdAt) und behandle ihn als Idempotency-Key.

Wenn du das Prinzip sauber umsetzen willst (inkl. Dedupe-Store und Checkliste): Idempotenz in Automationen

4) Plane Retries ein

Wenn dein System kurz down ist, sollte das nicht bedeuten, dass Daten verloren sind. Zwei robuste Wege:

Du akzeptierst den Webhook schnell und verarbeitest später (Queue).
Du lässt den Provider bei 5xx retryn (dann brauchst du aber saubere Deduplizierung).

Polling robust bauen (damit es nicht nervt)

Polling ist nicht "Cronjob mit GET /items". Polling wird stabil, wenn du einen sauberen Delta-Mechanismus hast.

1) Poll nicht "alles" - poll Deltas

Gute APIs bieten:

since Parameter
Cursor/Pagination
updatedAt / modifiedSince
ETag / If-Modified-Since

Wenn du nur einen harten "Liste alles" Endpoint hast, wird Polling teuer und fragil. Dann brauchst du eine lokale State-Strategie (z.B. letzte ID, letzter Zeitstempel).

2) Backoff und Jitter statt fixer Intervalle

Wenn ein Endpoint langsam wird oder Rate Limits greift, solltest du automatisch runterregeln.

Praktischer Standard:

Exponentieller Backoff bei Fehlern (z.B. 1m, 2m, 4m, 8m ... bis max).
Jitter (kleine Zufallsabweichung), damit nicht alles zur vollen Minute gleichzeitig feuert.

Wenn du Retries und Rate Limits strukturiert bauen willst: Retries, Backoff & Rate Limits

3) Polling heißt auch: Monitoring

Bei Polling ist der wichtigste Alarm nicht "ein Request ist fehlgeschlagen", sondern:

"Seit X Stunden wurde nichts mehr synchronisiert."
"Der Cursor/Checkpoint bewegt sich nicht."

Wenn du das nicht siehst, merkst du den Fehler erst beim Kunden.

Kombinationsmuster: Webhook + Abgleich (sehr empfehlenswert)

Wenn du eine Automation wirklich zuverlässig willst, kombiniere beide:

Webhook verarbeitet neue Events schnell.
Ein täglicher/wochentlicher Polling-Job vergleicht: Fehlt etwas? (Reconcile)

Das ist besonders hilfreich, wenn:

Provider Webhooks zwar anbietet, aber nicht garantiert zustellt.
dein System gelegentlich deployt/down ist.
du "am Monatsende muss alles stimmen" Anforderungen hast.

Passender Kontext aus der Praxis: Buchhaltung & Monatsabschluss

Typische Fehler (und wie du sie vermeidest)

Webhook ohne Signaturprüfung. Das ist eine Einladung für Spam und im schlimmsten Fall Datenmanipulation.
Webhook verarbeitet "alles" synchron. Das endet in Timeouts, Retries, Duplikaten und Chaos.
Polling ohne Delta-Strategie. Dann wirst du irgendwann von Rate Limits, Kosten oder Laufzeiten gebremst.
Kein Dedupe/Idempotenz. Irgendwann hast du doppelte Tickets, doppelte Mails oder doppelte Einträge.
Kein "stilles" Monitoring. Du merkst den Fehler erst, wenn jemand schreit. Das ist zu spät.

FAQ

Was ist besser: Webhook oder Polling?

Keins ist pauschal besser. Webhook ist besser für schnelle, event-getriebene Prozesse. Polling ist besser für Batch-/Backoffice-Prozesse oder wenn Webhooks nicht verfügbar sind.

Wie oft sollte ich pollen?

So selten wie möglich, so oft wie nötig.

Praktisch:

Backoffice: 1x pro Stunde oder 1x pro Tag reicht oft.
Operativ: 5-15 Minuten, wenn das Risiko überschaubar ist.

Wenn du minütliche Reaktionszeit brauchst, ist ein Webhook meist die bessere Basis.

Kann ich Webhooks in Make/n8n nutzen?

Ja. Tools wie Make, n8n oder Pipedream können Webhook-Endpoints bereitstellen und Events als Trigger nutzen. Der wichtige Teil bleibt aber gleich: verifizieren (wenn möglich), deduplizieren und Fehler sichtbar machen.

Wenn du Tooling einordnen willst: Make vs. Alternativen

Transparenz

Dieser Blog kann Affiliate-Links enthalten. Aktuell liegt der Fokus auf Inhalten und Workflows. Wenn später Links ergänzt werden, werden sie klar gekennzeichnet.

Nächster Schritt

Der Rahmen für stabile Automationen: Workflow-Automatisierung.
Tool-Beispiel aus der Praxis: Make für IT-Freelancer.
Zur Übersicht: Workflows: Automatisierung.