Webhook
Dernière mise à jour:
Ce qu'est un webhook
On parle aussi de rappel HTTP (HTTP callback) ou d'API inversée. Avec un appel d'API classique, votre programme demande des données à un autre système. Avec un webhook, vous enregistrez une URL une seule fois, choisissez les événements qui vous intéressent, et l'autre système appelle cette URL chaque fois que l'un d'eux survient. Le message est généralement une requête POST avec un corps JSON qui décrit l'événement.
L'alternative est le polling : interroger une API toutes les quelques minutes pour détecter les changements. Le polling gaspille des requêtes quand rien ne s'est passé et retarde les mises à jour quand quelque chose a changé. Les webhooks évitent ces deux écueils.
Comment il fonctionne
Un webhook implique un émetteur et un destinataire :
- Le destinataire crée un endpoint, une URL sur son propre serveur qui accepte les requêtes en HTTPS.
- Dans les paramètres de l'émetteur, il enregistre cette URL et choisit les événements auxquels s'abonner.
- Quand un événement se produit, l'émetteur envoie à l'URL un payload JSON avec le type d'événement et ses données.
- Le destinataire vérifie que la requête est authentique, répond rapidement avec un code de statut 2xx, puis traite les données. Sans réponse de succès, l'émetteur réessaie généralement plus tard.
Exemple
Une boutique en ligne veut que son logiciel d'entrepôt connaisse chaque nouvelle commande. Au lieu que le logiciel interroge la boutique toutes les minutes, la boutique envoie un webhook à l'endpoint du logiciel à chaque commande. Le payload contient le numéro de commande, les articles et l'adresse de livraison, et la préparation peut commencer en quelques secondes.
Bonnes pratiques pour recevoir des webhooks
Un endpoint de webhook est une URL publique, il faut donc traiter chaque requête entrante avec prudence :
- Vérifiez la signature. Beaucoup d'émetteurs signent chaque payload avec un secret partagé, souvent via HMAC, pour que vous puissiez confirmer que la requête vient bien d'eux et n'a pas été modifiée en route.
- Utilisez HTTPS pour que les payloads, qui peuvent contenir des données personnelles, soient chiffrés pendant le transfert.
- Répondez vite. Renvoyez immédiatement un statut 2xx et faites le travail long en arrière-plan, sinon l'émetteur risque de considérer l'envoi comme échoué.
- Prévoyez les doublons. Les nouvelles tentatives peuvent livrer deux fois le même événement : utilisez son identifiant pour ne le traiter qu'une fois. On parle d'idempotence.
Pourquoi c'est important pour les chatbots d'entreprise
Les webhooks relient un chatbot au reste de l'entreprise sans que personne ait à surveiller un tableau de bord. Une plateforme de chatbot peut envoyer un webhook à la fin d'une conversation ou à la capture d'un lead, pour qu'un CRM, un tableur ou un outil d'automatisation le reçoive aussitôt. En comparant des outils de chatbot, vérifiez quels événements ils peuvent envoyer et si les payloads sont signés.
Ce que propose intoCHAT à la place
intoCHAT n'envoie pas de webhooks et n'a pas d'intégration Zapier ou Make. Les nouveaux leads vous parviennent de deux façons : une alerte e-mail à chaque nouveau lead, envoyée au propriétaire et jusqu'à 5 autres adresses, et le tableau des leads, où vous pouvez filtrer les leads, ouvrir la conversation de chacun et les exporter en CSV vers votre CRM ou votre outil d'e-mailing.
Les actions API personnalisées d'intoCHAT fonctionnent autrement que les webhooks. L'agent appelle votre API HTTP pendant un chat quand la conversation le demande, par exemple pour vérifier un prix ou une disponibilité, et non automatiquement lors d'un événement fixe. Elles apportent des données en direct dans les réponses, mais ne transmettent pas chaque lead à un autre système.