English
FrançaisDeux directions
GoHighLevel peut envoyer un webhook depuis n'importe quelle étape de workflow vers une URL que vous contrôlez, et peut recevoir des webhooks qui créent ou mettent à jour des contacts via un déclencheur de webhook entrant. La plupart des intégrations utilisent les deux : un workflow envoie des données à un service qui fait ce que la plateforme ne sait pas faire, et le service réécrit le résultat.
Sortant, depuis un workflow
L'action « Webhook » d'un workflow envoie du JSON à votre point de terminaison. N'incluez que ce dont le service a besoin : identifiant du contact, les deux ou trois champs concernés et le nom de l'événement. Des charges volumineuses avec chaque champ rendent le débogage pénible et laissent fuir des données que le service ne devrait pas détenir. Ajoutez un en-tête personnalisé avec un secret partagé pour que le récepteur puisse vérifier que l'appel vient de votre compte.
Recevoir en sécurité
Nos récepteurs, généralement une fonction serverless, font quatre choses dans l'ordre : vérifier le secret et rejeter tout le reste ; extraire un identifiant d'événement (ou en construire un à partir de l'identifiant du contact, du nom de l'événement et de l'horodatage) et ignorer les doublons ; répondre immédiatement par un 200 ; puis effectuer le vrai travail en arrière-plan. Répondre vite compte parce que la plateforme réessaiera un point de terminaison lent, et vous avez alors le même événement deux fois.
Concevez chaque action pour que l'exécuter deux fois donne le même résultat que l'exécuter une fois. Mettre à jour un champ est idempotent. Ajouter une note ne l'est pas, sauf si vous vérifiez que la note n'existe pas déjà.
Entrant, vers GoHighLevel
Un déclencheur de webhook entrant vous donne une URL ; tout ce qui y envoie du JSON peut démarrer un workflow, et le workflow associe la charge aux champs du contact. Nous gardons la correspondance des champs à un seul endroit, le workflow lui-même, avec un tableau de nommage à côté dans la documentation du compte. Les formulaires de sites sur d'autres plateformes, les systèmes partenaires et nos propres services envoient tous à ces déclencheurs.
Erreurs et nouvelles tentatives
Les services échouent. Les nôtres interceptent chaque erreur, la journalisent avec l'identifiant d'événement et publient un court message dans un canal surveillé, selon la même approche que nos règles de pile d'automatisation. Les échecs passagers (délai dépassé lors de l'appel d'une API tierce) sont retentés avec temporisation. Les échecs permanents (une charge mal formée) sont journalisés et ignorés, jamais retentés indéfiniment. L'équipe apprend les problèmes par l'alerte, pas par un client.
Journaliser dans la chronologie
Quoi que fasse un service, il écrit une note d'une ligne sur le contact : « Devis calculé : 4 200 $ (tarification v3). Envoyé au commercial. » Cette note rend l'intégration déboguable par une personne non développeuse. Quand quelque chose semble faux, le chargé de compte ouvre le contact et voit exactement ce qui s'est passé et quand.
L'essentiel à retenir
- Les webhooks sortants des workflows portent le contact et les valeurs personnalisées que vous choisissez ; gardez la charge petite et explicite.
- Chaque récepteur vérifie un secret partagé, dédoublonne par identifiant d'événement et répond vite, en faisant le vrai travail de façon asynchrone.
- Les webhooks entrants permettent à des systèmes externes de créer ou de mettre à jour des contacts ; associez les champs une fois, à un seul endroit.
- Attendez-vous à des nouvelles tentatives. Concevez chaque action pour qu'exécuter deux fois soit sans danger.
- Écrivez une note sur le contact pour tout ce que fait un service, pour que l'équipe le voie sans ouvrir de code.