Connecter GoHighLevel à Kajabi : paiement et accès aux cours

Pour connecter un paiement GoHighLevel à un espace membre Kajabi, il faut transmettre l’achat confirmé, puis accorder la bonne offre Kajabi au bon client. Un lien vers la formation, un contact créé ou une page de remerciement ne suffisent pas à ouvrir les accès. Le parcours présenté ici utilise un workflow HighLevel et Zapier ; une variante par webhook Kajabi convient aux équipes capables de maintenir cette connexion.

Le point décisif n’est pas seulement « le client entre-t-il ? », mais aussi « que se passe-t-il en cas de doublon, de remboursement ou de fin d’abonnement ? ». Voici comment préparer la connexion et la vérifier avant d’envoyer du trafic vers votre formation.

Documentation consultée le 2 octobre 2026. Guide de configuration et de contrôle, sans test d’achat revendiqué sur vos comptes. Les menus, permissions et fonctions disponibles dépendent de vos abonnements.

Garder Kajabi ou migrer les cours : deux projets différents

Si vos apprenants restent sur Kajabi et que votre acquisition passe par GoHighLevel, vous cherchez une connexion entre paiement et accès. Vous ne cherchez pas à déplacer vos vidéos. L’importeur Kajabi de HighLevel sert à migrer des cours ; ce n’est pas une synchronisation permanente des ventes et des droits.

• Page de vente GHL, paiement Kajabi : un bouton peut envoyer l’acheteur vers le checkout Kajabi. Vérifiez ensuite séparément le retour des informations vers votre CRM.
• Paiement GHL, cours Kajabi : prévoyez l’automatisation d’attribution d’offre décrite ci-dessous, ainsi que le traitement des accès à retirer.
• Cours et communauté dans GHL : utilisez les fonctions de cette plateforme ; notre guide du portail et des accès GoHighLevel couvre ce parcours distinct.

Ne résiliez pas Kajabi pour réaliser une simple connexion. Et n’annoncez pas une connexion native universelle dans un menu « Checkout → Intégrations → Kajabi » : ce parcours n’est pas établi par les documentations utilisées ici.

Préparer l’offre, les comptes et la correspondance des produits

Commencez par une seule offre et un contact de test. Notez le sous-compte HighLevel, le produit et le tarif vendus, le site Kajabi et l’offre qui donne accès aux contenus promis. Une offre peut réunir plusieurs produits : vérifiez son contenu, pas seulement son nom.

Avant d’acheter une option : la documentation Kajabi réserve les webhooks aux plans Growth et Pro et rappelle cette restriction dans sa fiche Zapier. Vérifiez votre éligibilité dans votre compte, notamment sur un ancien abonnement. Webhooks by Zapier n’est pas disponible sur son plan gratuit, selon sa documentation consultée. Côté HighLevel, contrôlez aussi la disponibilité et la facturation des actions premium si vous les utilisez. Aucun coût total fixe n’est promis ici.

Préparez une fiche de correspondance courte :

• Ce qui est acheté : identifiant du produit et du tarif GHL, paiement unique ou récurrent.
• Ce qui est ouvert : site et offre Kajabi, cours inclus, éventuelle durée d’accès.
• À qui : nom, adresse e-mail vérifiée et identifiant de suivi stable.
• Ce qui doit fermer l’accès : événements retenus, date d’effet et personne responsable des exceptions.

Exemple fictif : une formation « Création publicitaire vidéo » et une offre « Formation + retours individuels » peuvent partager un cours, mais pas les mêmes services. Ne branchez pas les deux tarifs sur la même offre par commodité si cela donne gratuitement l’accompagnement réservé à la seconde.

Connecter le paiement à Kajabi avec Zapier

1. Déclencher le workflow sur un paiement réussi

Dans le workflow HighLevel, sélectionnez Payment Received. Filtrez au minimum le statut sur Success et le produit concerné ; ajoutez le tarif et la source lorsque votre configuration les propose. Ce déclencheur peut aussi traiter des événements en échec et des renouvellements : son nom ne dispense pas de filtrer. La fiche officielle Payment Received décrit ces critères.

Une soumission de formulaire n’est pas votre preuve d’encaissement. Si vous devez encore construire les pages et tester leurs liens, commencez par le guide du tunnel GoHighLevel.

2. Recevoir l’événement dans Zapier

Créez un Zap avec Webhooks by Zapier → Catch Hook. Copiez l’URL générée. Dans le workflow GHL, ajoutez une action Webhook en POST vers cette URL. Envoyez un événement de test identifié, puis utilisez Test trigger dans Zapier pour examiner les données reçues. Ces opérations sont décrites dans les guides officiels Catch Hook et Webhook sortant HighLevel.

Vérifiez les valeurs réellement transmises : nom, e-mail, produit, statut et référence de transaction si elle est fournie. Le contenu reçu dépend du déclencheur. N’inventez pas un nom de variable absent du sélecteur. Notre guide Zapier–GoHighLevel détaille la préparation des données et les contrôles d’automatisation.

3. Attribuer la bonne offre Kajabi

Ajoutez Kajabi comme application d’action, puis choisissez Grant Access to an Offer. Connectez le compte autorisé, choisissez le bon site et la bonne offre, puis associez les champs demandés aux données reçues. La documentation Kajabi–Zapier distingue cette attribution de l’action Revoke Access to an Offer, qui retire l’accès d’un client.

Testez avec une boîte e-mail que vous contrôlez, puis ouvrez le cours avec ce compte apprenant. L’attribution d’une offre ne constitue pas un nouvel encaissement Kajabi : gardez une seule référence de vente pour votre suivi. La fiche Grant an Offer distingue bien accès accordé et achat via checkout.

4. Prévoir le message d’accès et les exceptions

Ne supposez pas qu’une exécution réussie dans Zapier signifie que l’apprenant a reçu son invitation. Vérifiez le message Kajabi effectivement envoyé, les préférences du destinataire et son accès. Si vous ajoutez un message GHL, évitez deux invitations contradictoires. Il doit indiquer où se connecter et qui contacter, jamais contenir un mot de passe réutilisable en clair.

Conservez les URL de webhook et les secrets dans les réglages autorisés, pas dans le code public de votre page de vente ou dans une capture diffusée. Ne transmettez pas de données de carte bancaire à cette automatisation d’accès.

Variante : le webhook d’activation Kajabi

Pour éviter l’intermédiaire Zapier, Kajabi expose une URL d’activation et une URL de désactivation propres à chaque offre. Le parcours documenté est Sales → offre concernée → More Actions → Webhooks. Le webhook entrant exige un nom, un e-mail et un external_user_id. Conservez la même convention d’identité pour attribuer et retirer les droits. Voir les webhooks Kajabi.

L’action Custom Webhook de HighLevel permet de choisir la méthode, les en-têtes et le corps de requête. Cette variante exige de vérifier le format accepté par Kajabi avec vos données de test ; ce guide ne fournit pas de requête « universelle » présentée comme exécutée. Les journaux Kajabi permettent de contrôler la réception et les erreurs.

Choisissez un seul chemin d’attribution. Activer simultanément le webhook direct et un Zap pour la même vente rend les doublons et les incidents plus difficiles à comprendre.

Remboursement et résiliation : traiter l’accès séparément

HighLevel documente des déclencheurs Refund et Subscription. Ils permettent de construire des workflows distincts du paiement initial. Filtrez l’offre concernée et le statut effectif : une tentative de remboursement n’est pas nécessairement un remboursement réussi.

• Remboursement : décidez de l’effet attendu selon l’offre et les conditions applicables. Un remboursement partiel ne doit pas déclencher automatiquement la même règle qu’un remboursement intégral sans décision préalable.
• Résiliation : distinguez la demande d’arrêt du renouvellement et la fin des droits déjà payés. Ne coupez pas immédiatement un accès qui doit courir jusqu’à une échéance future.
• Impayé : définissez le traitement, les éventuelles relances et la vérification avant retrait. Ne confondez pas une tentative échouée et une situation définitivement non régularisée.

Appliquez ensuite la décision d’accès via Revoke Access to an Offer ou le webhook de désactivation de l’offre. Retirer un accès n’est pas rembourser ni annuler un prélèvement. Contrôlez ces opérations séparément dans le système qui encaisse. Attention également aux autres achats du même client : le retrait d’une offre ne doit pas annuler des droits acquis par ailleurs.

Huit tests avant de vendre la formation

Cette recette est un protocole à exécuter sur vos comptes, pas un résultat de test revendiqué. Préparez des comptes de test et isolez les événements de test des clients réels. Pour toute vérification avec un paiement réel, faites valider le montant et les frais possibles par le responsable du compte.

1. Premier achat : une transaction confirmée attribue la bonne offre ; le nouveau membre ouvre la première leçon sans droits administrateur.
2. Paiement refusé : aucun accès payant n’est accordé. Testez aussi un produit non concerné par cette automatisation.
3. Client déjà connu : l’achat complémentaire rejoint le bon compte Kajabi et conserve les formations acquises précédemment.
4. Événement rejoué : la même transaction ne déclenche pas une seconde séquence de bienvenue. Prévoyez un contrôle des références déjà traitées ; un simple tag de contact ne suffit pas à distinguer toutes ses commandes.
5. Renouvellement : le paiement suivant suit la règle prévue, sans répéter l’accueil initial ni changer arbitrairement la date d’accès.
6. Remboursement : le scénario intégral et, si proposé, le scénario partiel produisent exactement les droits attendus, sans toucher aux autres achats.
7. Fin d’abonnement : l’accès cesse à la bonne échéance ; une reconnexion et l’URL directe du cours confirment le résultat.
8. Incident et mobile : un événement en erreur est repéré et repris sans double attribution ; l’invitation reçue sur téléphone mène au bon cours.

Pour chaque test, gardez la référence de transaction, l’heure, la référence d’exécution GHL/Zapier, l’offre attendue et une preuve côté apprenant. Un statut HTTP 200 indique une réponse technique : il ne prouve pas que la bonne personne voit le bon contenu. Contrôlez aussi une absence d’accès lorsqu’elle est attendue.

Le paiement est confirmé, mais le cours reste inaccessible

Remontez la chaîne dans l’ordre : transaction → filtre GHL → envoi du webhook → action Kajabi → compte et droits du membre. Si le Zap n’a rien reçu, inspectez l’envoi ; s’il a reçu les données mais échoué, inspectez son action ; si l’action est réussie, comparez e-mail, site, offre et dates d’accès. Ne multipliez pas les achats de test pour masquer une erreur de correspondance.

Autre piège : la documentation Kajabi précise qu’un webhook sortant Purchase Created ne se déclenche pas pour une offre simplement accordée. Ne construisez donc pas une boucle qui attend cet événement pour confirmer une attribution issue de GHL. Votre contrôle doit porter sur le résultat de l’action et les droits constatés.

Vidéo complémentaire : Sell in Highlevel: Connecting Stripe & Adding Products in Gohighlevel Funnels — Allie Bloyd. Lecture vérifiée le 2 octobre 2026, en anglais, environ sept minutes. Elle illustre la partie Stripe/produits du tunnel, pas la connexion Kajabi ni la recette ci-dessus ; les libellés visibles peuvent différer de votre version.

Critère de livraison : la vente ouvre les droits attendus, les exceptions sont testées et quelqu’un sait traiter les événements en erreur. C’est cette chaîne vérifiable, plutôt qu’une promesse d’intégration « en un clic », qui permet de confier votre parcours de formation à l’automatisation.