Einen Endpunkt erstellen

Schritt 1: Einen virtuellen Workflow erstellen

Öffnen Sie den Bereich Workflows und wählen Sie Neu.
Datensatztyp: der virtuelle Typ.
Quelle: Listener.

So erhalten Sie einen Workflow, dessen Startpunkt der Endpunkt-Listener ist.

Schritt 2: Den Endpunkt-Listener hinzufügen

Fügen Sie auf der Builder-Oberfläche den Inbound-Endpunkt-Listener als ersten Schritt des Workflows hinzu. Dieser Block erstellt und verwaltet die öffentliche URL. Er verfügt über die folgenden Einstellungen.

Die URL (schreibgeschützt)

Die Adresse des Endpunkts setzt sich aus zwei automatisch generierten Hashes zusammen:

/listener/{first_hash}/{second_hash}

first_hash und second_hash werden für Sie generiert und schreibgeschützt angezeigt.
Zusammen bilden sie die vollständige öffentliche URL, an die ein externes System Daten sendet, zum Beispiel: https://your-flexie-domain/listener/a1b2c3…/f6e5d4…

Da die URL zwei lange Zufalls-Hashes enthält, ist sie praktisch nicht zu erraten. Behandeln Sie sie dennoch als Geheimnis und fügen Sie für alles Sensible besser eine Authentifizierung hinzu (siehe unten).

Antworttyp (erforderlich)

return_type legt fest, was der Aufrufer zurückbekommt. Es gibt fünf Optionen:

`return_type`	Was der Aufrufer erhält
data	Ein Antwortkörper, den Sie definieren (JSON, XML oder HTML, der Typ wird automatisch erkannt)
html	Eine HTML-Seite, die Sie definieren
redirect	Eine HTTP-Weiterleitung an eine von Ihnen definierte URL
continue	Die Antwort wird später durch einen Schritt im Workflow erzeugt, für dynamische Antworten
sse	Eine live gestreamte Antwort (Server-Sent Events), die vom Workflow erzeugt wird

Diese werden ausführlich unter Dem Aufrufer antworten behandelt. Für einen einfachen „Empfangen, danke"-Endpunkt wählen Sie data und geben einen kurzen Antwortkörper an. Das passende Feld erscheint je nach Ihrer Wahl:

data: return_data (der Antwortkörper; Flexie Scripting erlaubt)
html: return_html (das HTML; Flexie Scripting erlaubt)
redirect: return_redirect (die Ziel-URL; Flexie Scripting erlaubt)

Schritt 3: Authentifizierung hinzufügen (empfohlen)

Aktivieren Sie add_authentication, damit Aufrufer ihre Identität mit einem JSON Web Token (JWT) nachweisen müssen. Bei aktivierter Option:

Einstellung	Bedeutung
`endpoint_key`	Der erwartete Aussteller des Tokens (der `iss`-Claim). Aufrufer müssen ein unter diesem Schlüssel ausgestelltes Token vorlegen. Automatisch generiert; Sie können ihn ändern. Unterstützt Flexie Scripting.
`endpoint_secret`	Das gemeinsame Geheimnis, mit dem das Token signiert und verifiziert wird. Automatisch generiert; Sie können es ändern. Unterstützt Flexie Scripting. Durch Ändern des Werts rotieren Sie es.

Worauf es ankommt, wenn das aufrufende System sein Token erstellt:

Unterstützt werden ausschließlich die Signaturalgorithmen HS256, HS384 und HS512.
Es gilt eine Toleranz von 60 Sekunden für Uhrenabweichungen (geringfügige Zeitunterschiede führen also nicht zur Ablehnung gültiger Tokens).
Der Aufrufer sendet das Token im Header Authorization: Bearer <token> (ein einfacher token-Header wird ebenfalls akzeptiert).
Ein fehlendes Token liefert 403. Ein ungültiges, abgelaufenes oder mit falschem Aussteller versehenes Token liefert 401.

Ohne Authentifizierung kann jeder, der die URL kennt, sie aufrufen. Mit Authentifizierung können das nur Aufrufer, die ein gültig signiertes Token für Ihren Aussteller besitzen.

Das vollständige Protokoll, die Claim-Struktur, die Behandlung von Uhrenabweichungen, den data-Claim, die Details zu Fehlerantworten, die CORS-Preflight-Falle und sofort anpassbare Code-Beispiele in Node.js, Python, PHP, Go, .NET, Java, Ruby, curl und Flexie selbst finden Sie unter Authentifizierung & CORS im Detail.

Schritt 4: Cross-Origin-Regeln (nur wenn ein Browser ihn aufruft)

Wird der Endpunkt direkt aus einem Webbrowser aufgerufen (vom Frontend Ihrer Website), aktivieren Sie allow_cors und listen Sie die erlaubten Origins auf:

Einstellung	Bedeutung
`allow_cors`	Aktiviert die Cross-Origin-Behandlung (einschließlich Preflight-Anfragen).
`cors_domains`	Kommagetrennte Liste der erlaubten Origins, z. B. `https://app.example.com,https://staging.example.com`, oder `*`, um alle zuzulassen. Unterstützt Flexie Scripting.

Wird der Endpunkt nur Server-zu-Server aufgerufen (der übliche Fall bei Webhooks), brauchen Sie kein CORS.

Die Kombination aus JWT-Auth und CORS birgt eine echte Falle. Eine Browser-Preflight-Anfrage mit OPTIONS wird von der JWT-Prüfung abgelehnt, weil der Preflight kein Authorization mitführt. Brauchen Sie beides, leiten Sie den Browser-Aufruf über Ihr eigenes Backend um oder verwenden Sie stattdessen eine im Antwortkörper transportierte Signatur. Siehe Authentifizierung & CORS im Detail.

Schritt 5: Die Schritte bauen, testen, veröffentlichen

Fügen Sie unterhalb des Listeners die Entscheidungen und Aktionen des Workflows hinzu und nutzen Sie die eingehenden Daten wie unter Daten empfangen beschrieben. Anschließend testen und veröffentlichen Sie wie bei jedem Workflow (siehe Einen Workflow bauen).

Der Endpunkt funktioniert nur, wenn der Workflow veröffentlicht ist. Die URL eines unveröffentlichten virtuellen Workflows nimmt keine Anfragen an.

Ihre Endpunkte finden

Die öffentliche URL wird am Endpunkt-Listener innerhalb seines Workflows angezeigt. Flexie stellt autorisierten Aufrufern zudem eine Liste der veröffentlichten Endpunkte über eine Auflistung der dynamischen Endpunkte bereit, nützlich für ein integrierendes System, um zu ermitteln, was verfügbar ist.

Nächste Schritte

Daten empfangen: wie aus der Anfrage nutzbare Werte werden.
Dem Aufrufer antworten: die fünf Antworttypen im Detail.
Authentifizierung & CORS im Detail: das JWT-Protokoll, die CORS-Regeln, die Preflight-Falle und Code-Beispiele in acht Sprachen.