Comment fonctionne un webhook ?
Vous enregistrez une URL — le point de terminaison — auprès du système qui détient les données, et vous lui indiquez quels événements vous intéressent. Quand l'un de ces événements survient, ce système envoie une requête HTTP POST vers votre point de terminaison avec une charge utile décrivant ce qui s'est passé, généralement en JSON. Votre serveur lit la charge utile, fait son travail et renvoie un code 2xx pour accuser réception. Aucune requête de votre part ne l'a déclenché — la source a agi d'elle-même. La plupart des fournisseurs signent chaque requête pour que vous puissiez confirmer qu'elle vient bien d'eux.
Webhook ou polling d'API : quelle différence ?
Le polling, c'est le modèle pull : votre code demande à une API « quoi de neuf ? » selon un planning fixe, que quelque chose ait changé ou non. Un webhook, c'est le modèle push : la source vous appelle seulement quand il y a quelque chose à signaler. Le polling gaspille la plupart de ses requêtes et ajoute de la latence entre l'événement et votre réaction ; les webhooks arrivent en quelques secondes et restent silencieux le reste du temps. En contrepartie, votre point de terminaison doit être accessible publiquement et prêt à absorber des pics.
Comment les plateformes d'engagement utilisent-elles les webhooks ?
- Sortant — un nœud webhook dans un parcours envoie un POST à un système externe en cours de route : prévenir Slack quand un prospect convertit, synchroniser un statut vers votre CRM, déclencher une étape de traitement.
- Entrant — un récepteur ingère les événements d'autres outils : un prestataire de paiement signale un paiement réussi, un outil de formulaire transmet un nouveau prospect, si bien que les profils et les parcours réagissent sans import nocturne.
- Cette plomberie bidirectionnelle est ce qui permet à une plateforme d'engagement client de se placer au centre de votre stack. Des services de livraison dédiés comme Knock se spécialisent dans le seul volet sortant.
Pourquoi c'est important pour une petite équipe
Une équipe de deux personnes ne peut pas rester à interroger les changements, et les tâches cron qui vérifient toutes les quelques minutes ajoutent à la fois de la latence et du coût. Les webhooks laissent un outil réagir à un autre dès que quelque chose se produit, sans personne pour surveiller. Deux précautions : comme n'importe quel appelant peut envoyer un POST à une URL publique, vérifiez la signature de chaque requête et traitez le corps comme non fiable ; et journalisez les événements que vous émettez et recevez pour qu'ils correspondent à votre plan de tracking au lieu de devenir un canal parallèle non tracé.