L'essentiel à retenir : l'API v1 de GoHighLevel n'est plus supportée depuis le 31 décembre 2025, et HighLevel retire la création de nouvelles clés API. Pour connecter un outil externe en 2026, tu passes par un Private Integration Token (PIT) pour tes propres intégrations, ou par OAuth 2.0 si tu construis une app destinée à d'autres comptes. Les clés historiques peuvent continuer à fonctionner, mais elles sont marquées expirées si elles restent inutilisées 90 jours.
Si un Zap, un scénario Make ou un petit script maison alimente ton CRM avec une vieille clé API, ce guide est pour toi. On voit ce qui a changé, comment créer un token, comment migrer en limitant les risques d'interruption, et quand l'API devient utile (ou inutile) pour une agence. Il s'appuie sur la documentation officielle HighLevel, consultée début octobre 2026.
Ce qui a changé : API v1, clés API et API v2
Pendant des années, connecter HighLevel à un autre outil se résumait à copier une clé API dans les réglages. Cette clé donnait accès à l'API v1, et à tout le compte. La page officielle sur l'API (mise à jour le 18 août 2026) est désormais claire :
- l'API v1 a atteint sa fin de support le 31 décembre 2025 ;
- les intégrations v1 existantes peuvent continuer à fonctionner, mais sans mise à jour ni support ;
- la création de nouvelles clés API est retirée des réglages agence et sous-compte.
S'ajoute une règle de sécurité : selon la page API Security Initiatives, une clé historique inutilisée depuis 90 jours est marquée « Expired ». Les clés actives ne sont pas touchées. Une clé expirée reste visible dans les réglages et peut resservir après rotation. HighLevel indique que des notifications par email peuvent précéder cette expiration.
Ton intégration v1 tourne encore ? Elle n'est plus maintenue : si elle tombe en panne, aucune mise à jour ni aucun support ne sont prévus pour cette version.
Private Integration Token ou OAuth 2.0 : lequel choisir ?
L'API v2 propose deux modes d'authentification. Le bon choix dépend surtout de qui va utiliser l'intégration.
| Private Integration Token (PIT) | OAuth 2.0 | |
|---|---|---|
| Pour qui | Outils internes, ton compte agence ou un sous-compte précis | Apps publiques ou du Marketplace, installées sur des comptes tiers |
| Création | En quelques clics dans Settings → Private Integrations | Échange d'un code d'autorisation contre des tokens, côté code |
| Durée de vie | Statique, sans rafraîchissement automatique (renouvelé seulement par rotation) | Le token d'accès expire chaque jour et doit être rafraîchi |
| Permissions | Scopes (permissions d'accès) choisis à la création, modifiables ensuite | Scopes approuvés par l'utilisateur qui installe l'app |
| Complexité | Faible : un header à renseigner | Plus élevée : flux d'autorisation et stockage des tokens |
La documentation Private Integrations (mise à jour le 29 septembre 2026) résume bien l'idée : un PIT est un token d'accès OAuth 2.0 statique, généré depuis l'interface. HighLevel le destine aux outils internes et aux usages sur un seul compte : c'est le cas typique d'une agence qui relie ses propres outils (Make, Zapier, n8n, un formulaire maison). OAuth devient utile quand tu développes une application installée par d'autres comptes. HighLevel le recommande aussi pour accéder à plusieurs comptes avec une autorisation donnée par l'utilisateur.
Côté plans, la FAQ officielle évoque un accès API « basique » sur Starter et Unlimited, et un accès avancé (OAuth, tokens niveau agence) sur Agency Pro, en précisant que certains endpoints sont réservés aux plans supérieurs. Vérifie le détail sur la page tarifs avant de bâtir ton offre ; on fait le point sur les plans dans notre guide prix et tarifs GoHighLevel.
Créer un Private Integration Token, étape par étape
Les Private Integrations existent au niveau agence comme au niveau sous-compte. Le chemin est le même : Settings → Private Integrations. Au niveau agence, si l'entrée n'apparaît pas, la doc indique de vérifier que la fonctionnalité est activée dans Labs.
- Clique sur Create new Integration.
- Donne un nom et une description explicites, par exemple « Make – synchro leads Facebook ».
- Coche uniquement les scopes nécessaires. Un outil qui lit les contacts n'a pas besoin des paiements.
- Copie le token généré et range-le dans un gestionnaire de mots de passe. HighLevel ne l'affiche qu'une fois.
Quelques règles utiles, toutes tirées de la doc officielle :
- 20 tokens maximum au niveau agence, et 20 par sous-compte ;
- tu peux modifier le nom, la description et les scopes après coup, sans changer le token ;
- par défaut, tous les admins agence peuvent créer et gérer des Private Integrations. Tu peux restreindre ce droit par utilisateur dans Settings → Team → Roles & Permissions (on détaille la logique dans notre guide équipe et permissions).
Pour un premier contrôle, la doc donne cet exemple avec un token de niveau agence (lecture des détails d'un sous-compte, qui demande le scope correspondant). Le token se place dans le header Authorization, avec le header Version exigé par l'endpoint :
curl --request GET \
--url https://services.leadconnectorhq.com/locations/TON_LOCATION_ID \
--header 'Accept: application/json' \
--header 'Authorization: Bearer TON_TOKEN' \
--header 'Version: 2021-07-28'Remplace TON_LOCATION_ID par l'identifiant du sous-compte. Ce test vérifie l'authentification, pas toute ton intégration. La liste complète des endpoints se trouve dans la documentation développeur HighLevel, qui propose désormais un sélecteur de version.
Migrer une vieille clé API en limitant les risques
HighLevel publie un guide de migration (mis à jour le 21 août 2026). Sa règle n° 1 : ne modifie pas tes automatisations en production. Tu construis les nouvelles à côté, tu testes, puis tu coupes les anciennes.
- Inventaire. Liste chaque outil qui utilise ta clé (Zapier, Make, n8n, formulaire maison…) et ce qu'il fait, par exemple « Zapier : envoie les leads Facebook dans HighLevel ».
- Un token par outil. Crée une Private Integration distincte pour chacun. Ne partage jamais un même token entre plusieurs outils : en cas de fuite, tu ne révoques qu'un accès.
- Nouvelles automatisations. Duplique ton scénario (l'original reste en sauvegarde) et connecte la copie avec le nouveau token. Vérifie le mode d'authentification accepté par ton connecteur ; pour une requête HTTP directe, le token part en header
Authorization: Bearer <token>. Dans les apps HighLevel de Zapier ou Make, choisis les actions les plus récentes. - Test. Fais passer un lead de test et vérifie dans le CRM que les données arrivent au bon endroit. Si une action échoue, contrôle selon le code d'erreur les scopes, les identifiants, l'endpoint et le format de la requête.
- Bascule. Active les nouvelles automatisations, mets les anciennes en pause, puis supprime la vieille clé de tes outils et de HighLevel.
L'erreur à éviter : croire que seule l'authentification change. La doc prévient que les requêtes et les réponses peuvent différer entre l'ancienne API et l'actuelle. Un mapping de champs qui marchait en v1 peut demander des ajustements. Si tu utilises Make, notre guide Make + GoHighLevel montre comment structurer les scénarios.
Sécurité : rotation, fuite et limites d'appels
Renouveler ses tokens
HighLevel recommande une rotation tous les 90 jours. Dans la fiche de l'intégration, « Rotate and expire this token later » génère un nouveau token. L'ancien et le nouveau fonctionnent ensemble pendant 7 jours, le temps de mettre à jour tes outils. Pendant cette fenêtre, tu peux annuler la rotation ou faire expirer l'ancien token tout de suite.
Token compromis
Token publié par erreur dans un dépôt Git ou envoyé au mauvais prestataire ? Choisis « Rotate and expire this token now » : l'ancien token cesse de fonctionner, tu reportes le nouveau dans tes outils légitimes. Avec un token par outil, seul l'accès exposé saute ; tes autres intégrations continuent de tourner.
Limites d'appels
La documentation API fixe ces plafonds pour les API publiques v2 utilisées via OAuth :
- 100 requêtes par tranche de 10 secondes ;
- 200 000 requêtes par jour.
Ils s'appliquent par app Marketplace et par ressource (un sous-compte ou une agence) ; la doc ne détaille pas de plafond distinct pour les PIT, garde donc ces valeurs comme repère. Les headers de réponse X-RateLimit-Remaining et X-RateLimit-Daily-Remaining te disent où tu en es. Pour un import massif, espace tes appels plutôt que de tout envoyer d'un coup.
L'API n'est pas toujours nécessaire : les alternatives sans code
Avant de créer un token, demande-toi si le besoin ne se règle pas dans HighLevel.
- Envoyer des données vers un autre outil : l'action de workflow Custom Webhook fait des requêtes GET, POST, PUT ou DELETE vers n'importe quelle URL. Elle gère l'authentification par Bearer token, clé API, Basic Auth ou OAuth2, et injecte des valeurs dynamiques comme
{{contact.email}}. Pour la logique des déclencheurs et actions, vois notre guide des workflows. - Relier une app grand public : regarde d'abord si elle existe dans l'App Marketplace. La doc présente l'installation d'une app comme la première option, la Private Integration comme la seconde.
- Stocker une donnée métier : avant de monter une base externe, regarde si les objets personnalisés couvrent ton besoin. Voir notre guide des objets personnalisés.
L'API devient pertinente quand tu dois lire des données HighLevel depuis l'extérieur (tableau de bord maison, synchro avec un ERP), créer des contacts depuis un système qui n'a pas de connecteur, ou industrialiser des opérations répétitives sur plusieurs sous-comptes.
Bonus : brancher un assistant IA via le serveur MCP
HighLevel propose aussi un serveur MCP (Model Context Protocol). Il permet à un client IA compatible (Cursor, Windsurf, un client compatible Claude, une app maison…) de consulter en langage naturel les contacts, conversations, calendriers, opportunités et paiements, et d'effectuer certaines actions d'écriture, notamment sur les contacts, les messages et les opportunités.
L'authentification repose sur le même Private Integration Token, créé au niveau du sous-compte. Ton client IA reçoit l'URL du serveur (https://services.leadconnectorhq.com/mcp/), puis deux headers : le token en Authorization: Bearer et l'identifiant du sous-compte en locationId. Les outils visibles par l'IA dépendent des scopes accordés. La règle du strict minimum vaut donc encore plus ici : une IA qui peut envoyer des messages à tes contacts mérite un token limité, dédié et surveillé.
Récap : ta checklist API GoHighLevel 2026
| Action | Pourquoi |
|---|---|
| Recenser les outils branchés sur une vieille clé API | API v1 sans support depuis le 31/12/2025 |
| Créer un PIT par outil, avec les permissions strictement nécessaires | Limiter l'accès et révoquer finement |
| Dupliquer, tester, puis basculer | Limiter les risques d'interruption en production |
| Planifier une rotation tous les 90 jours | Recommandation officielle, 7 jours de recouvrement |
| Surveiller les headers de rate limit | Repères documentés (OAuth) : 100 requêtes/10 s et 200 000/jour par app et par ressource |
| Préférer Custom Webhook ou Marketplace quand c'est possible | Moins de code à maintenir |
Dernier point : le support HighLevel ne fait ni audit de code ni accompagnement de développement sur l'API. Les bugs se signalent via le portail développeur, et les questions se posent dans la communauté Slack des développeurs. Si tu fais appel à un freelance, donne-lui un token dédié, jamais tes identifiants. Et s'il développe une app OAuth, les SDK officiels Python et PHP gèrent l'échange et le rafraîchissement des tokens.
