What's new, 21 October 2026: A customer who sends several messages before the bot's first reply no longer gets the opening sequence of a Chat Flow twice
WASync · Developers

HTTP-Anfrage-Schritt in Chat Flows

Fragen Sie aus einem Flow heraus per HTTPS ein externes System ab und verwenden Sie die Antwort in den nächsten Schritten. Von wo die Anfrage gesendet wird, was sie aufrufen darf und wie Sie die Antwort zuordnen.

Ein Chat Flow kann ein externes System per HTTPS etwas fragen und die Antwort in der Unterhaltung verwenden: eine Bestellung nachschlagen, einen Kontostand prüfen, einen Liefertermin abrufen. Der Schritt heißt HTTP request (Palettengruppe Integrate) im Chat Flows-Editor der WASync-App in Bitrix24.

Was der Schritt tut

  1. Er baut die Anfrage aus den Einstellungen des Schritts auf: Methode (GET oder POST), URL, Header und bei POST einen Body. {{VARIABLES}} aus früheren Schritten sowie aus dem Lead oder Deal werden eingesetzt: In der URL werden sie URL-kodiert, in einem JSON-Body JSON-maskiert.
  2. Er führt die Anfrage aus und wartet bis zu 10 Sekunden auf die Antwort.
  3. Er ordnet die JSON-Antwort mit dem response mapping Flow-Variablen zu: links ein JSON-Pfad (data.order.status, items[0].id), rechts ein Variablenname (ESTADO). Die nächsten Schritte verwenden diese wie jede andere Antwort: {{ESTADO}} in einer Nachricht, eine Bedingung in einem Branch, ein Wert in Fill in a field.

Jeder Aufruf setzt außerdem drei Variablen:

VariableWert
HTTP_STATUSDer HTTP-Statuscode, mit dem das System geantwortet hat (200, 404, …), leer, wenn nichts geantwortet hat.
HTTP_OKtrue bei einer 2xx-Antwort, sonst false.
HTTP_ERRORLeer bei Erfolg; andernfalls ein kurzer Code: http_404, timeout, blocked_url, upstream_unreachable, budget_exceeded, breaker_open.

Zwei ausgehende Kanten

Der Knoten hat eine normale Kante (Erfolg) und eine rote error-Kante. Die Fehlerkante wird genommen, wenn der Aufruf in ein Timeout läuft, die URL abgelehnt wird, das System mit 4xx oder 5xx antwortet oder das Netzwerk ausfällt. Ist die Fehlerkante nicht verbunden, läuft der Flow auf der normalen Kante mit HTTP_OK = false weiter, sodass ein Branch auf HTTP_OK trotzdem reagieren kann.

Von wo die Anfrage gesendet wird

Die Anfrage wird nicht von den Servern von WASync gesendet. Sie wird von einem dedizierten Cloudflare Worker (egress.wasync.app) ausgeführt, der keinen Zugriff auf die internen Systeme von WASync hat. Daraus folgt zweierlei:

  • Der Aufruf erreicht Ihr System aus den IP-Bereichen von Cloudflare, nicht von einer festen WASync-Adresse. Erlaubt Ihre API nur gelistete IPs, verwenden Sie stattdessen einen API key oder eine Signatur; es gibt keine WASync-IP, die Sie freigeben könnten.
  • Eine langsame oder ausfallende API kann WhatsApp-Nachrichten nie verzögern oder doppelt auslösen: Der Aufruf läuft außerhalb der Nachrichten-Pipeline, und der Flow wartet an dem Schritt bis zur Antwort oder zum Timeout.

Was der Schritt aufrufen darf

RegelWert
Schema und Portnur https auf Port 443
HostEin öffentlicher Domainname. IP-Adressen, localhost, .local, .internal, Namen mit nur einem Label und die eigenen Domains von WASync werden abgelehnt.
MethodenGET, POST
HeaderBis zu 16. Transport- und Proxy-Header (Host, Transfer-Encoding, Proxy-*, Cookie, X-Forwarded-*, …) werden abgelehnt; Authorization, X-Api-Key, Content-Type, Accept und Ähnliches sind erlaubt.
Request-BodyBis zu 64 KB
AntwortEs werden bis zu 256 KB gelesen; längere Bodys werden abgeschnitten, und im Test wird truncated gemeldet.
Timeout10 Sekunden
WeiterleitungenHöchstens 2, jede wird nach denselben Regeln geprüft
Budget600 Aufrufe pro Workspace und Stunde. Ein Host, der 5-mal in Folge fehlschlägt, wird für 5 Minuten pausiert (in dieser Zeit wird die Fehlerkante genommen).
LizenzDie Lizenz der Nummer muss aktiv sein; der Schritt läuft nicht während einer Testphase.

Der User-Agent lautet immer WASync-Flows/1.0 (+https://wasync.app).

Geheimnisse

Markieren Sie einen Header als secret (einen API key, ein Bearer-Token), und WASync speichert ihn verschlüsselt. Er wird im Editor nie wieder angezeigt, nie mit dem Flow exportiert und nie in Logs oder im Audit-Trail festgehalten. Um ihn zu ändern, geben Sie einen neuen Wert ein; um ihn zu behalten, lassen Sie das Feld beim Speichern leer.

Vor dem Speichern testen

Test request im Panel des Schritts führt den echten Aufruf mit Beispielwerten für die Variablen aus und zeigt Status, Dauer, die zugeordneten Variablen und den Body. Use as sample response speichert diesen Body im Schritt: Der Simulator verwendet ihn, statt das System aufzurufen, sodass sich der gesamte Flow offline in der Vorschau ansehen lässt.

Beispiel: Bestellstatus

  • Question: "¿Cuál es tu número de pedido?" (gespeichert als PEDIDO)
  • HTTP request: GET https://erp.example.com/api/orders/{{PEDIDO}}, Header X-Api-Key (secret), Zuordnung data.status → ESTADO, data.eta → ENTREGA
  • Branch auf HTTP_OK: true → Message Tu pedido está {{ESTADO}}, llega el {{ENTREGA}}. · false → Message No pude consultar tu pedido ahora, un asesor te escribe en breve. → Hand to a person

In dieser Version nicht enthalten

PUT, PATCH und DELETE; OAuth gegenüber dem externen System; automatische Wiederholungen; Dateidownloads; Warten auf einen Callback des Systems. Für diese Fälle bleibt das Ausweichrezept: Der Flow schreibt ein CRM-Feld, eine Bitrix24-Automatisierungsregel benachrichtigt Ihr System, Ihr System schreibt das Ergebnis über die Bitrix24 REST API zurück, und die Regel WASync: Send WhatsApp Message sendet es.

Jeder Aufruf wird im Audit-Trail des Workspace protokolliert (Host und Pfad, Status, Dauer, welche Variablen gesetzt wurden; nie der Body oder die Header).

War diese Seite hilfreich?

On this page