HTTP-Trigger

Workflows über einen Webhook starten — synchron oder asynchron.

Geschrieben von Thomas Seidl

Zuletzt aktualisiert Vor etwa 1 Monat

Was der Baustein macht

Der HTTP-Trigger ist der Einstiegspunkt für Workflows, die nicht durch einen Anruf, sondern durch einen HTTP-Request gestartet werden — einen Webhook oder API-Aufruf aus einem anderen System.

Damit baust du Abläufe, die gar nichts mit Telefonie zu tun haben müssen: ein Formular auf deiner Website, ein Ereignis im CRM, ein nächtlicher Job aus deiner eigenen Infrastruktur.

Typische Anwendungsfälle

  • Ein Formular auf einer Website startet einen Ablauf.
  • Ein CRM oder Ticketsystem übergibt Daten an Lane One.
  • Ein externer Dienst löst eine Terminbuchung oder eine Datenerfassung aus.
  • Eine eigene Anwendung bindet einen Agenten an.

Die Webhook-URL

Lane One stellt für den Trigger eine URL bereit, die das aufrufende System ansteuert. Sie enthält die Workflow-Definition und kann zusätzlich einen optionalen Pfad tragen — praktisch, um mehrere Aufrufe voneinander zu unterscheiden.

Behandle die URL wie ein Geheimnis. Wer sie kennt, kann den Ablauf auslösen.

Der Ausführungsmodus

Unter Ausführungsmodus triffst du die wichtigste Entscheidung dieses Bausteins.

Synchron

Der Aufrufer wartet auf die Antwort des Workflows — maximal 10 Sekunden. Verwende diesen Modus, wenn der Aufrufer das Ergebnis unmittelbar braucht, etwa für eine Prüfung, deren Resultat direkt angezeigt wird.

Die Zeitgrenze ist der entscheidende Punkt: Alles, was im Ablauf länger dauern kann — mehrere Integrationsaufrufe, ein langsames Zielsystem — passt nicht in den synchronen Modus. Für die Antwort selbst brauchst du am Ende den Baustein HTTP Antwort.

Asynchron

Der Aufrufer erhält sofort eine Bestätigung (HTTP 202) mit einer Execution-ID. Der Workflow läuft danach im Hintergrund weiter; das Ergebnis kann über die ID nachträglich abgefragt werden.

Das ist der robustere Weg für alles, was dauern kann. Der Aufrufer blockiert nicht und läuft nicht in einen Timeout.

Den Request-Body beschreiben

Unter Beispiel-Request-Body definierst du die erwartete Struktur der eingehenden Daten. Die Felder stehen den nachfolgenden Bausteinen dann als Variablen zur Verfügung.

Das lohnt sich immer: Ohne beschriebene Struktur musst du die Felder in jedem Folgeschritt von Hand referenzieren, und Tippfehler fallen erst zur Laufzeit auf.

Worauf du achten solltest

  • Im Zweifel asynchron. Synchron nur, wenn der Aufrufer die Antwort wirklich sofort braucht und der Ablauf sicher unter 10 Sekunden bleibt.
  • Beispiel-Body pflegen, bevor du den restlichen Ablauf baust.
  • Plane ein, was passieren soll, wenn Pflichtfelder im Request fehlen — ein Bedingung prüfen gleich hinter dem Trigger erspart später Rätselraten.