2.8 Webhooks, Polling, Trigger und Zeitpläne

Automatisierte Workflows benötigen einen Auslöser.

Dieser Auslöser wird als Trigger bezeichnet.

Typische Trigger sind:

Ein Trigger bestimmt, wann ein Workflow gestartet wird.

Lernziele

Nach dieser Seite solltest du erklären können:

Trigger

Ein Trigger ist ein Ereignis, das einen automatisierten Workflow startet.

Beispiele:

Trigger Mögliche Aktion
neuer Mitarbeiter Benutzerkonto anlegen
neuer CRM-Kunde Projekt erstellen
neue Supportanfrage IT benachrichtigen
fehlgeschlagener Dienst Alarm senden
täglicher Zeitpunkt Bericht erzeugen
manuelle Ausführung Testworkflow starten

Grundablauf:

Trigger
   |
   v
Daten prüfen
   |
   v
Aktionen ausführen
   |
   v
Ergebnis protokollieren

Webhook

Ein Webhook ist eine automatische Nachricht, die beim Eintritt eines Ereignisses an ein anderes System gesendet wird.

Beispiel:

Im CRM wurde ein neuer Kunde angelegt.

Das CRM sendet die Kundendaten direkt an n8n.

CRM
 |
 | Webhook
 v
n8n
 |
 v
Workflow startet

Der Webhook enthält häufig JSON-Daten.

Beispiel:

{
  "event": "customer.created",
  "customerId": 125,
  "company": "Musterfirma GmbH"
}

Webhook-Endpoint

Damit ein System einen Webhook senden kann, benötigt es eine Zieladresse.

Beispiel:

https://automation.example.com/webhook/new-customer

Diese Adresse wird als Webhook-Endpoint oder Webhook-URL bezeichnet.

Ablauf:

  1. n8n stellt einen Webhook-Endpoint bereit.
  2. Die Webhook-URL wird im Quellsystem eingetragen.
  3. Im Quellsystem tritt ein Ereignis ein.
  4. Das Quellsystem sendet einen HTTP-Request.
  5. n8n empfängt die Daten.
  6. Der Workflow wird gestartet.

Webhook als HTTP-Request

Ein Webhook verwendet häufig die HTTP-Methode POST.

Beispiel:

POST /webhook/new-employee

Content-Type: application/json

{
  "name": "Max Mustermann",
  "department": "IT",
  "startDate": "2026-08-03"
}

Der Empfänger antwortet beispielsweise mit:

Status: 200 OK

Oder:

Status: 202 Accepted

Vorteile von Webhooks

Nachteile von Webhooks

Ein Webhook kann mehrfach eintreffen oder vollständig ausbleiben. Der Workflow muss darauf vorbereitet sein.

Polling

Polling bedeutet:

Ein System fragt regelmäßig bei einem anderen System nach neuen Daten.

Beispiel:

n8n fragt alle fünf Minuten beim CRM:

Gibt es neue Kunden?

Ablauf:

n8n
 |
 | API-Abfrage
 v
CRM
 |
 | neue Daten vorhanden?
 v
Antwort an n8n

Beispiel:

GET /customers?createdAfter=2026-07-17T10:00:00

Polling-Intervall

Das Polling-Intervall legt fest, wie häufig eine Abfrage ausgeführt wird.

Beispiele:

Ein sehr kurzes Intervall sorgt für schnelle Reaktionen, erzeugt aber viele API-Anfragen.

Ein langes Intervall reduziert die Last, kann aber zu Verzögerungen führen.

Webhook und Polling im Vergleich

Merkmal Webhook Polling
Auslösung Quellsystem sendet aktiv Zielsystem fragt regelmäßig
Geschwindigkeit meistens sofort abhängig vom Intervall
API-Anfragen nur bei Ereignissen auch ohne neue Daten
Einrichtung Webhook-Unterstützung notwendig API-Abfrage ausreichend
Fehlerfall Nachricht kann verloren gehen nächster Abruf kann Daten finden
Rate Limits meist geringer belastet können schneller erreicht werden

Merksatz:

Beim Webhook meldet das Quellsystem ein Ereignis. Beim Polling fragt das Zielsystem regelmäßig danach.

Wann ist ein Webhook sinnvoll?

Ein Webhook eignet sich besonders:

Beispiele:

Wann ist Polling sinnvoll?

Polling eignet sich besonders:

Beispiele:

Zeitplan-Trigger

Ein Zeitplan-Trigger startet einen Workflow zu einem festgelegten Zeitpunkt oder Intervall.

Beispiele:

Mögliche Aufgaben:

Cron-Ausdruck

Zeitpläne können mit Cron-Ausdrücken beschrieben werden.

Beispiel:

0 8 * * 1-5

Bedeutung:

Montag bis Freitag um 08:00 Uhr

Grundaufbau:

Stelle Bedeutung
1 Minute
2 Stunde
3 Tag des Monats
4 Monat
5 Wochentag

Weitere Beispiele:

Cron-Ausdruck Bedeutung
0 8 * * * täglich um 08:00 Uhr
0 9 * * 1 montags um 09:00 Uhr
*/15 * * * * alle 15 Minuten
0 0 1 * * am ersten Tag des Monats

Die genaue Cron-Unterstützung kann je nach System unterschiedlich sein.

Manueller Trigger

Ein Workflow kann auch manuell gestartet werden.

Dies ist sinnvoll für:

Ein manueller Trigger sollte nicht unkontrolliert auf Produktivdaten angewendet werden.

Vorher sollten geprüft werden:

Ereignisgesteuerter Workflow

Ein ereignisgesteuerter Workflow reagiert auf ein bestimmtes Ereignis.

Beispiel:

Mitarbeiter im Personalsystem freigegeben
                     |
                     v
              Webhook an n8n
                     |
                     v
                Daten prüfen
                     |
                     v
         Benutzerkonto vorbereiten
                     |
                     v
              IT benachrichtigen

Das Ereignis ist in diesem Fall:

Mitarbeiter wurde freigegeben.

Webhook-Sicherheit

Webhook-Endpunkte können über das Internet erreichbar sein.

Deshalb müssen sie geschützt werden.

Mögliche Maßnahmen:

Ein öffentlicher Webhook darf eingehende Daten niemals automatisch als vertrauenswürdig behandeln.

Webhook-Signatur

Ein Quellsystem kann eine Signatur mitsenden.

Beispiel:

X-Webhook-Signature: abc123

Der Empfänger berechnet selbst eine Signatur aus:

Stimmen beide Signaturen überein, wurde die Nachricht wahrscheinlich nicht verändert und stammt vom erwarteten Absender.

Replay-Angriff

Bei einem Replay-Angriff wird ein gültiger Webhook erneut gesendet.

Mögliche Folgen:

Schutzmaßnahmen:

Beispiel:

{
  "eventId": "evt-98452",
  "event": "employee.created"
}

Vor der Verarbeitung wird geprüft, ob evt-98452 bereits verarbeitet wurde.

Doppelte Webhooks

Webhooks können mehrfach gesendet werden, wenn das Quellsystem keine erfolgreiche Antwort erhält.

Beispiel:

  1. Quellsystem sendet Webhook.
  2. n8n verarbeitet den Vorgang.
  3. Die Antwort an das Quellsystem erreicht den Absender nicht.
  4. Das Quellsystem sendet den Webhook erneut.

Der Workflow muss deshalb idempotent aufgebaut sein.

Möglicher Ablauf:

Webhook empfangen
      |
      v
Event-ID prüfen
      |
      v
bereits verarbeitet?
   /       \
 ja         nein
 |           |
 v           v
stoppen   verarbeiten

Verlorene Webhooks

Ein Webhook kann verloren gehen, wenn:

Mögliche Schutzmaßnahmen:

Eine Kombination aus Webhook und gelegentlichem Polling kann besonders zuverlässig sein.

Webhook-Antwort

Der Empfänger sollte schnell eine passende HTTP-Response senden.

Beispiele:

Statuscode Bedeutung
200 Webhook erfolgreich verarbeitet
202 Webhook angenommen, Verarbeitung folgt
400 Daten fehlerhaft
401 Authentifizierung fehlt
403 Zugriff nicht erlaubt
500 interner Fehler

Bei umfangreichen Workflows kann zuerst 202 Accepted zurückgegeben und die eigentliche Verarbeitung anschließend durchgeführt werden.

Praxisbeispiel: IT-Onboarding

Ein Personalsystem sendet einen Webhook:

{
  "eventId": "evt-10025",
  "event": "employee.approved",
  "employee": {
    "name": "Max Mustermann",
    "department": "IT",
    "startDate": "2026-08-03"
  }
}

Möglicher Workflow:

  1. Signatur prüfen
  2. Event-ID prüfen
  3. Pflichtfelder validieren
  4. Startdatum kontrollieren
  5. Benutzerkonto vorbereiten
  6. Projektaufgabe erstellen
  7. Slack-Nachricht senden
  8. Ergebnis protokollieren
  9. Event-ID als verarbeitet speichern

Praxisbeispiel: Polling

Ein SaaS-System unterstützt keine Webhooks.

n8n fragt alle 15 Minuten:

GET /employees?modifiedAfter=2026-07-17T12:00:00

Möglicher Ablauf:

  1. letzten erfolgreichen Abrufzeitpunkt laden
  2. neue oder geänderte Datensätze abrufen
  3. Datensätze prüfen
  4. jeden Datensatz verarbeiten
  5. Ergebnisse protokollieren
  6. neuen Abrufzeitpunkt speichern

Der letzte Abrufzeitpunkt darf erst gespeichert werden, wenn die Verarbeitung erfolgreich abgeschlossen wurde.

Zeitzonen

Zeitplan-Trigger müssen die richtige Zeitzone verwenden.

Beispiel:

Europe/Berlin

Probleme können entstehen durch:

Ein Workflow um 08:00 Uhr sollte eindeutig festlegen, welche Zeitzone gemeint ist.

Monitoring

Trigger und Workflows sollten überwacht werden.

Wichtige Kontrollen:

Beispiel:

Wenn seit 24 Stunden kein erwarteter Webhook empfangen wurde, wird die IT informiert.

Systematische Fehlersuche

Wenn ein Workflow nicht startet:

  1. Ist der Workflow aktiviert?
  2. Ist der richtige Trigger konfiguriert?
  3. Ist die Webhook-URL korrekt?
  4. Ist der Endpoint erreichbar?
  5. Wird die richtige HTTP-Methode verwendet?
  6. Wird der Webhook im Quellsystem ausgelöst?
  7. Sind Authentifizierung oder Signatur gültig?
  8. Ist der Zeitplan korrekt?
  9. Ist die richtige Zeitzone eingestellt?
  10. Wurde ein Rate Limit erreicht?
  11. Gibt es einen Fehler im Trigger-Log?
  12. Wurde das Ereignis möglicherweise als Duplikat erkannt?

Wichtige Begriffe

Begriff Bedeutung
Trigger startet einen Workflow
Webhook aktive Ereignismeldung eines Systems
Polling regelmäßige Abfrage nach Änderungen
Zeitplan festgelegter Ausführungszeitpunkt
Cron Schreibweise für wiederkehrende Zeitpläne
Event-ID eindeutige Kennung eines Ereignisses
Idempotenz doppelte Ausführung erzeugt keine zusätzlichen Änderungen
Replay-Angriff erneutes Senden einer gültigen Nachricht
Signatur Nachweis von Herkunft und Unverändertheit
Retry erneuter Übertragungsversuch
Zeitzone regionale Grundlage einer Zeitangabe

Gesamtmerksatz

Trigger starten automatisierte Workflows. Webhooks melden Ereignisse aktiv und meist sofort, während Polling regelmäßig nach neuen Daten fragt. Zeitplan-Trigger starten Workflows zu festgelegten Zeiten. Sichere und zuverlässige Automatisierungen müssen doppelte, verlorene und manipulierte Ereignisse berücksichtigen.

Kontrollfragen

Was ist ein Trigger?

Ein Ereignis oder Zeitpunkt, der einen Workflow startet.

Was ist ein Webhook?

Eine automatische HTTP-Nachricht, die beim Eintritt eines Ereignisses an ein anderes System gesendet wird.

Was bedeutet Polling?

Ein System fragt regelmäßig nach neuen oder geänderten Daten.

Was ist der wichtigste Unterschied zwischen Webhook und Polling?

Beim Webhook sendet das Quellsystem aktiv. Beim Polling fragt das Zielsystem regelmäßig nach.

Was ist ein Zeitplan-Trigger?

Ein Trigger, der einen Workflow zu einer festgelegten Zeit oder in einem bestimmten Intervall startet.

Warum muss eine Event-ID geprüft werden?

Damit ein Ereignis nicht mehrfach verarbeitet wird.

Warum müssen Webhook-Daten validiert werden?

Weil ein öffentlich erreichbarer Endpoint manipulierte oder fehlerhafte Daten empfangen kann.

Was ist ein Replay-Angriff?

Eine bereits gültige Nachricht wird erneut gesendet.

Warum ist die Zeitzone bei Zeitplänen wichtig?

Weil der Workflow sonst zu einer falschen Uhrzeit ausgeführt werden kann.

Wann kann eine Kombination aus Webhook und Polling sinnvoll sein?

Wenn Ereignisse sofort verarbeitet und möglicherweise verlorene Webhooks später durch eine Kontrollabfrage erkannt werden sollen.

Quellen

Revision #1
Created 16 July 2026 23:44:36 by Admin
Updated 16 July 2026 23:44:53 by Admin