HTTP request step in Chat Flows
Ask an external system over HTTPS from a flow and use the answer in the next steps. Where the request is made from, what it may call, and how to map the response.
A Chat Flow can ask an external system a question over HTTPS and use the answer in the conversation: look up an order, check a balance, fetch a delivery date. The step is called HTTP request (palette group Integrate) in the Chat Flows editor of the WASync app in Bitrix24.
What the step does
- Builds the request from the step's settings: method (GET or POST), URL, headers,
and for POST a body.
{{VARIABLES}}from earlier steps and from the lead or deal are substituted: in the URL they are URL-encoded, in a JSON body they are JSON-escaped. - Performs the request and waits up to 10 seconds for the answer.
- Maps the JSON answer onto flow variables with the response mapping: a JSON
path (
data.order.status,items[0].id) on the left, a variable name (ESTADO) on the right. The next steps use these like any answer:{{ESTADO}}in a message, a condition in a Branch, a value in Fill in a field.
Every call also sets three variables:
| Variable | Value |
|---|---|
HTTP_STATUS | The HTTP status code the system answered with (200, 404, …), empty if nothing answered. |
HTTP_OK | true for a 2xx answer, otherwise false. |
HTTP_ERROR | Empty on success; otherwise a short code: http_404, timeout, blocked_url, upstream_unreachable, budget_exceeded, breaker_open. |
Two outgoing edges
The node has a normal edge (success) and a red error edge. The error edge is
taken when the call times out, the URL is refused, the system answers 4xx or 5xx,
or the network fails. If the error edge is not connected, the flow continues on
the normal edge with HTTP_OK = false, so a Branch on HTTP_OK can still react.
Where the request is made from
The request is not made from WASync's servers. It is performed by a dedicated
Cloudflare Worker (egress.wasync.app) that has no access to WASync's internal
systems. Two consequences:
- The call reaches your system from Cloudflare's IP ranges, not from a fixed WASync address. If your API allows only listed IPs, use an API key or a signature instead; there is no WASync IP to allow-list.
- A slow or failing API can never delay or duplicate WhatsApp messages: the call runs outside the message pipeline, and the flow waits on the step until the answer or the timeout.
What the step may call
| Rule | Value |
|---|---|
| Scheme and port | https on port 443 only |
| Host | A public domain name. IP addresses, localhost, .local, .internal, single-label names and WASync's own domains are refused. |
| Methods | GET, POST |
| Headers | Up to 16. Transport and proxy headers (Host, Transfer-Encoding, Proxy-*, Cookie, X-Forwarded-*, …) are refused; Authorization, X-Api-Key, Content-Type, Accept and the like are fine. |
| Request body | Up to 64 KB |
| Response | Read up to 256 KB; longer bodies are cut, and truncated is reported in Test. |
| Timeout | 10 seconds |
| Redirects | At most 2, each checked against the same rules |
| Budget | 600 calls per workspace per hour. A host that fails 5 times in a row is paused for 5 minutes (the error edge is taken meanwhile). |
| Licence | The number's licence must be active; the step does not run on a trial. |
The user agent is always WASync-Flows/1.0 (+https://wasync.app).
Secrets
Mark a header as secret (an API key, a bearer token) and WASync stores it encrypted. It is never shown again in the editor, never exported with the flow, never written to logs or to the audit trail. To change it, type a new value; to keep it, leave the field empty when you save.
Test before you save
Test request in the step's panel performs the real call with sample values for the variables and shows the status, the time taken, the mapped variables and the body. Use as sample response stores that body on the step: the simulator uses it instead of calling the system, so the whole flow can be previewed offline.
Example: order status
- Question: "¿Cuál es tu número de pedido?" (saved as
PEDIDO) - HTTP request:
GET https://erp.example.com/api/orders/{{PEDIDO}}, headerX-Api-Key(secret), mappingdata.status→ESTADO,data.eta→ENTREGA - Branch on
HTTP_OK:true→ MessageTu pedido está {{ESTADO}}, llega el {{ENTREGA}}.·false→ MessageNo pude consultar tu pedido ahora, un asesor te escribe en breve.→ Hand to a person
Not in this version
PUT, PATCH and DELETE; OAuth towards the external system; automatic retries; file downloads; waiting for a callback from the system. For those, keep the sibling recipe: the flow writes a CRM field, a Bitrix24 automation rule notifies your system, your system writes the result back through the Bitrix24 REST API, and the WASync: Send WhatsApp Message rule sends it.
Every call is recorded in the workspace audit trail (host and path, status, duration, which variables were set; never the body or the headers).
Bring a number from another provider
Move a WhatsApp Business API number you already run at another provider onto WASync with the in-app wizard, and keep your reputation with Meta.
OAuth2 for third-party apps
Only for apps that other WASync customers install. Authorization Code with PKCE, rotating refresh tokens, and one structural limit.