Der universelle Webhook-Connector
Authentifizierte Aufrufe an jede API, eingehende Trigger mit HMAC-Verifizierung und paginierte Polling-Lesezugriffe — der Connector hinter jedem 'Wir integrieren mit X'.
Das ist der Connector, der 'jedes Tool' ehrlich macht. Ausgehend: HTTP-Aufrufe pro Datensatz mit Basic-, OAuth- (Auto-Refresh-und-Retry), API-Key- oder Bearer-Auth, eigenen Headern, JSON- oder XML-Bodies, einer optionalen JavaScript-Transformation pro Datensatz und Retries mit exponentiellem Backoff. Eingehend: Jeder Workflow erhält eine eindeutige Webhook-URL, gesichert per Secret-Header, mit optionaler HMAC-Signaturprüfung im GitHub-Stil. Und Lesezugriffe: ein Polling-Connector mit drei Paginierungsstrategien, Cursorn und inkrementellen Since-Zeitstempeln, der jede API in eine geplante Datenquelle verwandelt.
Workflow-Trigger
Eindeutige Inbound-URL pro Workflow
POST/PUT/DELETE an die URL des Workflows mit dem Secret-Code-Header startet den Flow.
HMAC-Signaturprüfung
Optionale SHA-256-Body-Signaturen (konfigurierbarer Header, GitHub-Stil oder rohes Hex, timing-sicherer Vergleich) für Quellen, die ihre Aufrufe signieren.
Draft-Test-Erfassung
Unveröffentlichte Workflows erfassen eine Beispiel-Payload, sodass der Designer Felder gegen echte Daten mappen kann, bevor es live geht.
Workflow-Aktionen
Jede API aufrufen
HTTP pro Datensatz mit Ihrem Auth-Modus, eigenen Headern, JSON- oder XML-Payloads, einer optionalen JS-Transformation pro Datensatz und 429/5xx-Retries mit Backoff.
OAuth-Refresh-und-Retry
Abgelaufene Tokens werden automatisch gegen Ihre Refresh-URL erneuert, und der Aufruf wird wiederholt.
So fließen die Daten
Bidirektional per Konstruktion: Jedes System, das HTTP senden kann, kann Ihre Workflows starten, und in jede API, gegen die Sie sich authentifizieren können, lässt sich schreiben oder aus ihr pollen — mit Paginierung (Link-Header, Next-URL-Pfade oder Page-Parameter), Cursorn und inkrementellen Since-Zeitstempeln im Format, das Ihre API erwartet.
Verbindung: Verbindungs-Zugangsdaten pro Workspace gespeichert: Basic Auth, OAuth mit Refresh-Token-URL, API-Key unter einem eigenen Header oder ein Bearer-Token.
Praxisbeispiel: Ein internes Tool ganz ohne 'Integration'
Erstellen Sie eine Webhook-Verbindung mit dem Bearer-Token Ihrer internen API.
Trigger: Qualifizierte Umfrageantworten durchlaufen den Workflow.
Aktion: Jeder Datensatz wird per POST an Ihren internen Endpunkt gesendet, umgeformt durch eine kleine JS-Transformation.
Ein geplanter Lesezugriff pollt dieselbe API jede Nacht auf Änderungen und paginiert bis zum Ende.
Fertige Flow-Templates
Installieren Sie ein mitgeliefertes Template und passen Sie es an — kein Aufbau von Grund auf nötig.
Einrichtung
1.
Erstellen Sie eine Webhook-Verbindung mit dem Auth-Modus Ihrer API.
2.
Für eingehend: Kopieren Sie die eindeutige URL und den Secret-Header des Workflows in das Quellsystem.
3.
Für Lesezugriffe: Konfigurieren Sie Paginierung und Since-Parameter einmalig; dann planen Sie den Lauf.
Häufige Fragen
Welche Auth-Modi werden unterstützt?
Basic Auth, OAuth mit automatischem Refresh-und-Retry, API-Key unter einem eigenen Header-Namen und Bearer-Tokens.
Wie werden eingehende Webhooks abgesichert?
Die URL jedes Workflows verlangt einen Secret-Code-Header, ergänzt um optionale HMAC-SHA256-Body-Signaturen (konfigurierbarer Header, timing-sicherer Vergleich).
Kann er APIs lesen, nicht nur aufrufen?
Ja — der Polling-Connector unterstützt Link-Header-, Next-URL- und Page/PageSize-Paginierung plus Cursor und inkrementelle Since-Zeitstempel und macht so jede API zu einer geplanten Datenquelle.