Étape « Requête HTTP » dans Chat Flows
Interrogez un système externe en HTTPS depuis un flux et utilisez la réponse dans les étapes suivantes. D'où part la requête, ce qu'elle peut appeler et comment mapper la réponse.
Un Chat Flow peut poser une question à un système externe en HTTPS et utiliser la réponse dans la conversation : consulter une commande, vérifier un solde, récupérer une date de livraison. L'étape s'appelle Requête HTTP (groupe de la palette Intégrer) dans l'éditeur Chat Flows de l'application WASync dans Bitrix24.
Ce que fait l'étape
- Elle construit la requête à partir des réglages de l'étape : méthode (GET ou POST), URL, en-têtes
et, pour POST, un corps. Les
{{VARIABLES}}des étapes précédentes et du lead ou du deal sont substituées : dans l'URL, elles sont encodées en URL ; dans un corps JSON, elles sont échappées pour JSON. - Elle exécute la requête et attend la réponse pendant 10 secondes au maximum.
- Elle associe la réponse JSON à des variables du flux grâce au mappage de la réponse : un chemin
JSON (
data.order.status,items[0].id) à gauche, un nom de variable (ESTADO) à droite. Les étapes suivantes les utilisent comme n'importe quelle réponse :{{ESTADO}}dans un message, une condition dans un Branch, une valeur dans Fill in a field.
Chaque appel définit aussi trois variables :
| Variable | Valeur |
|---|---|
HTTP_STATUS | Le code d'état HTTP renvoyé par le système (200, 404, …), vide si rien n'a répondu. |
HTTP_OK | true pour une réponse 2xx, sinon false. |
HTTP_ERROR | Vide en cas de succès ; sinon un code court : http_404, timeout, blocked_url, upstream_unreachable, budget_exceeded, breaker_open. |
Deux sorties
Le nœud a une sortie normale (succès) et une sortie rouge erreur. La sortie d'erreur est
empruntée lorsque l'appel expire, que l'URL est refusée, que le système répond 4xx ou 5xx,
ou que le réseau échoue. Si la sortie d'erreur n'est pas connectée, le flux continue sur
la sortie normale avec HTTP_OK = false : un Branch sur HTTP_OK peut donc quand même réagir.
D'où part la requête
La requête n'est pas émise depuis les serveurs de WASync. Elle est exécutée par un
Cloudflare Worker dédié (egress.wasync.app) qui n'a aucun accès aux systèmes internes de WASync.
Deux conséquences :
- L'appel arrive chez vous depuis les plages d'adresses IP de Cloudflare, et non depuis une adresse WASync fixe. Si votre API n'autorise que des adresses IP listées, utilisez plutôt une API key ou une signature : il n'existe aucune adresse IP WASync à autoriser.
- Une API lente ou en panne ne peut jamais retarder ni dupliquer des messages WhatsApp : l'appel s'exécute en dehors du pipeline des messages, et le flux attend sur l'étape jusqu'à la réponse ou jusqu'à l'expiration du délai.
Ce que l'étape peut appeler
| Règle | Valeur |
|---|---|
| Schéma et port | https sur le port 443 uniquement |
| Hôte | Un nom de domaine public. Les adresses IP, localhost, .local, .internal, les noms à une seule étiquette et les domaines propres de WASync sont refusés. |
| Méthodes | GET, POST |
| En-têtes | Jusqu'à 16. Les en-têtes de transport et de proxy (Host, Transfer-Encoding, Proxy-*, Cookie, X-Forwarded-*, …) sont refusés ; Authorization, X-Api-Key, Content-Type, Accept et similaires sont acceptés. |
| Corps de la requête | Jusqu'à 64 Ko |
| Réponse | Lue jusqu'à 256 Ko ; les corps plus longs sont tronqués, et truncated est signalé dans Test. |
| Délai d'expiration | 10 secondes |
| Redirections | 2 au maximum, chacune vérifiée selon les mêmes règles |
| Quota | 600 appels par espace de travail et par heure. Un hôte qui échoue 5 fois de suite est mis en pause pendant 5 minutes (la sortie d'erreur est alors empruntée). |
| Licence | La licence du numéro doit être active ; l'étape ne s'exécute pas pendant un trial. |
Le user agent est toujours WASync-Flows/1.0 (+https://wasync.app).
Secrets
Marquez un en-tête comme secret (une API key, un bearer token) et WASync le stocke chiffré. Il n'est plus jamais affiché dans l'éditeur, jamais exporté avec le flux, jamais écrit dans les journaux ni dans la piste d'audit. Pour le modifier, saisissez une nouvelle valeur ; pour le conserver, laissez le champ vide lors de l'enregistrement.
Tester avant d'enregistrer
Tester la requête dans le panneau de l'étape exécute l'appel réel avec des valeurs d'exemple pour les variables et affiche l'état, le temps écoulé, les variables mappées et le corps. Utiliser comme réponse d'exemple enregistre ce corps dans l'étape : le simulateur l'utilise à la place d'appeler le système, ce qui permet de prévisualiser tout le flux hors ligne.
Exemple : statut d'une commande
- Question : « ¿Cuál es tu número de pedido? » (enregistrée sous
PEDIDO) - Requête HTTP :
GET https://erp.example.com/api/orders/{{PEDIDO}}, en-têteX-Api-Key(secret), mappagedata.status→ESTADO,data.eta→ENTREGA - Branch sur
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
Absent de cette version
PUT, PATCH et DELETE ; OAuth vers le système externe ; nouvelles tentatives automatiques ; téléchargements de fichiers ; attente d'un rappel (callback) du système. Pour ces cas, conservez la recette voisine : le flux écrit dans un champ CRM, une règle d'automatisation Bitrix24 prévient votre système, votre système réécrit le résultat via l'API REST de Bitrix24, et la règle WASync: Send WhatsApp Message l'envoie.
Chaque appel est enregistré dans la piste d'audit de l'espace de travail (hôte et chemin, statut, durée, variables définies ; jamais le corps ni les en-têtes).
Apportez un numéro d'un autre fournisseur
Transférez vers WASync un numéro WhatsApp Business API que vous utilisez déjà chez un autre fournisseur, grâce à l'assistant intégré, et conservez votre réputation auprès de Meta.
Leads issus des conversations WhatsApp
Comment WASync transforme une nouvelle conversation WhatsApp en lead Bitrix24, à qui il l'attribue, ce qui se passe lorsque le numéro figure déjà dans votre CRM, et la fenêtre de re-contact qui maintient sur la même fiche un client qui réécrit après la clôture d'un lead.