Passaggio HTTP request in Chat Flows
Interroghi un sistema esterno via HTTPS da un flusso e usi la risposta nei passaggi successivi. Da dove parte la richiesta, che cosa può chiamare e come mappare la risposta.
Un Chat Flow può porre una domanda a un sistema esterno via HTTPS e usare la risposta nella conversazione: cercare un ordine, verificare un saldo, recuperare una data di consegna. Il passaggio si chiama HTTP request (gruppo della palette Integrate) nell'editor di Chat Flows dell'app WASync in Bitrix24.
Che cosa fa il passaggio
- Costruisce la richiesta in base alle impostazioni del passaggio: metodo (GET o POST), URL, header
e, per POST, un body. Le
{{VARIABLES}}dei passaggi precedenti e del lead o della deal vengono sostituite: nell'URL sono codificate come URL, in un body JSON sono sottoposte a escape JSON. - Esegue la richiesta e attende la risposta per un massimo di 10 secondi.
- Mappa la risposta JSON sulle variabili del flusso con la response mapping: un percorso
JSON (
data.order.status,items[0].id) a sinistra, un nome di variabile (ESTADO) a destra. I passaggi successivi le usano come qualsiasi risposta:{{ESTADO}}in un messaggio, una condizione in un Branch, un valore in Fill in a field.
Ogni chiamata imposta inoltre tre variabili:
| Variabile | Valore |
|---|---|
HTTP_STATUS | Il codice di stato HTTP con cui il sistema ha risposto (200, 404, …), vuoto se non ha risposto nessuno. |
HTTP_OK | true per una risposta 2xx, altrimenti false. |
HTTP_ERROR | Vuoto in caso di successo; altrimenti un codice breve: http_404, timeout, blocked_url, upstream_unreachable, budget_exceeded, breaker_open. |
Due uscite
Il nodo ha un collegamento normale (successo) e un collegamento rosso di errore. Il collegamento di errore
viene seguito quando la chiamata va in timeout, l'URL viene rifiutato, il sistema risponde 4xx o 5xx
oppure la rete non funziona. Se il collegamento di errore non è connesso, il flusso prosegue sul
collegamento normale con HTTP_OK = false, così un Branch su HTTP_OK può comunque reagire.
Da dove parte la richiesta
La richiesta non parte dai server di WASync. Viene eseguita da un Cloudflare Worker
dedicato (egress.wasync.app) che non ha accesso ai sistemi interni di WASync. Due conseguenze:
- La chiamata raggiunge il Suo sistema dagli intervalli IP di Cloudflare, non da un indirizzo fisso di WASync. Se la Sua API consente solo IP in elenco, usi una API key o una firma; non esiste un IP di WASync da inserire nella allowlist.
- Un'API lenta o in errore non può mai ritardare o duplicare i messaggi WhatsApp: la chiamata viene eseguita fuori dalla pipeline dei messaggi e il flusso resta in attesa sul passaggio fino alla risposta o al timeout.
Che cosa può chiamare il passaggio
| Regola | Valore |
|---|---|
| Schema e porta | Solo https sulla porta 443 |
| Host | Un nome di dominio pubblico. Indirizzi IP, localhost, .local, .internal, nomi a etichetta singola e i domini di WASync sono rifiutati. |
| Metodi | GET, POST |
| Header | Fino a 16. Gli header di trasporto e proxy (Host, Transfer-Encoding, Proxy-*, Cookie, X-Forwarded-*, …) sono rifiutati; Authorization, X-Api-Key, Content-Type, Accept e simili sono ammessi. |
| Body della richiesta | Fino a 64 KB |
| Risposta | Letta fino a 256 KB; i body più lunghi vengono troncati e in Test viene segnalato truncated. |
| Timeout | 10 secondi |
| Reindirizzamenti | Al massimo 2, ciascuno verificato con le stesse regole |
| Budget | 600 chiamate per workspace all'ora. Un host che fallisce 5 volte di seguito viene messo in pausa per 5 minuti (nel frattempo si segue il collegamento di errore). |
| Licenza | La licenza del numero deve essere attiva; il passaggio non viene eseguito durante una prova. |
Lo user agent è sempre WASync-Flows/1.0 (+https://wasync.app).
Segreti
Contrassegni un header come secret (una API key, un bearer token) e WASync lo conserva cifrato. Non viene più mostrato nell'editor, non viene mai esportato con il flusso e non viene mai scritto nei log né nell'audit trail. Per modificarlo, inserisca un nuovo valore; per mantenerlo, lasci il campo vuoto al salvataggio.
Provare prima di salvare
Test request nel pannello del passaggio esegue la chiamata reale con valori di esempio per le variabili e mostra lo stato, il tempo impiegato, le variabili mappate e il body. Use as sample response memorizza quel body nel passaggio: il simulatore lo usa al posto di chiamare il sistema, così l'intero flusso può essere visualizzato in anteprima offline.
Esempio: stato dell'ordine
- Question: "¿Cuál es tu número de pedido?" (salvato come
PEDIDO) - HTTP request:
GET https://erp.example.com/api/orders/{{PEDIDO}}, headerX-Api-Key(secret), mappingdata.status→ESTADO,data.eta→ENTREGA - Branch su
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
Non incluso in questa versione
PUT, PATCH e DELETE; OAuth verso il sistema esterno; nuovi tentativi automatici; download di file; attesa di un callback dal sistema. Per questi casi, usi la ricetta alternativa: il flusso scrive un campo CRM, una regola di automazione di Bitrix24 avvisa il Suo sistema, il Suo sistema scrive il risultato tramite la REST API di Bitrix24 e la regola WASync: Send WhatsApp Message lo invia.
Ogni chiamata viene registrata nell'audit trail del workspace (host e percorso, stato, durata, quali variabili sono state impostate; mai il body né gli header).
Portare un numero da un altro provider
Sposti su WASync, con la procedura guidata nell'app, un numero WhatsApp Business API che gestisce già presso un altro provider, mantenendo la reputazione presso Meta.
Lead da chat WhatsApp
Come WASync trasforma una nuova conversazione WhatsApp in un lead di Bitrix24, a chi viene assegnato, cosa succede quando il numero è già presente nel CRM e la finestra di ricontatto che mantiene sullo stesso record il cliente che scrive di nuovo dopo la chiusura di un lead.