Décrivez le problème/l’erreur/la question
le workflow n’enverra pas les données collectées à GoHighLevel
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
date:Wed, 13 May 2026 15:20:17 GMT
content-type:application/json; charset=utf-8
content-length:135
connection:close
cf-ray:9fb2a5733d929874-FRA
cf-cache-status:DYNAMIC
access-control-allow-origin:*
etag:W/"87-xaS8dZxdx/mn3i20TzmgTaBRUGI"
server:cloudflare
strict-transport-security:max-age=31536000
vary:Accept-Encoding
access-control-max-age:31536000
timing-allow-origin:*
x-envoy-upstream-service-time:7
x-powered-by:Express
x-ratelimit-daily-remaining:199993
x-ratelimit-daily-reset:32562000
x-ratelimit-interval-milliseconds:10000
x-ratelimit-limit-daily:200000
x-ratelimit-max:100
x-ratelimit-remaining:99
set-cookie
0:__cf_bm=dvz1DlV6m2XGv9TlMFsoDlk7CJssG9HtPoXoresrWk4-1778685617.1563067-1.0.1.1-BQCFZh_rmaWK7kRZ5DBdmNTFh6nJxMffroWqUMyaYuljatwRPEajw12Wp8MxOlea3zLYea5LOlSmZVyvaWL9Dhb6XvEM.6hhO8lEz6hDoYhFFt2N6VoB_Fj4R2Fz1dpv; HttpOnly; SameSite=None; Secure; Path=/; Domain=leadconnectorhq.com; Expires=Wed, 13 May 2026 15:50:17 GMT
Informations sur votre configuration n8n
- Version de n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
les en-têtes affichent un 200 donc GHL a bien reçu ta requête, le problème vient de ce que tu envoies.
la première chose que je ferais serait d’ouvrir la sortie du nœud HTTP Request dans n8n et de regarder le corps de la réponse réelle, pas seulement les en-têtes. GHL retourne parfois 200 mais cache un message d’erreur dans le corps comme un champ requis manquant ou un contact introuvable.
vérifie aussi tes noms de champs, GHL est strict sur la casse. firstName au lieu de first_name, phonePhone au lieu de phone, ce genre de choses. si une clé est incorrecte, il l’ignore simplement et continue, ce qui est super pénible à déboguer.
va dans GHL lui-même et vérifie si le contact a réellement été créé ou mis à jour. s’il est là mais que les champs sont vides, c’est un problème de mappage, s’il n’est pas là du tout, tu frappais peut-être au mauvais endpoint ou il te manque un champ requis comme un email ou un numéro de téléphone.
partage le corps que tu envoies et le corps de réponse réel et je peux te dire exactement ce qui ne va pas.
Bienvenue dans la communauté n8n @wathoo
Sans la charge utile de la demande et le corps de réponse réel, il n’y a pas assez de preuves pour déterminer s’il s’agit d’un problème interne n8n ou d’un problème de charge utile/mappage d’API.
exactement, c’est pour ça que j’ai demandé le corps de la réponse et la charge utile dans mon dernier message. une fois qu’ils partageront ça, on saura avec certitude de quel côté vient le problème.
Salut @wathoo, bienvenue dans la communauté ! Je suis Jay, un créateur vérifié n8n.
Un statut 200 avec un corps vide de GHL signifie généralement que la requête a atteint le serveur mais les données n’ont pas été traitées - c’est un problème de payload, pas de connexion. Voici quelques éléments à vérifier pendant que tu partages le corps/la réponse complète :
1. Le corps de la réponse est la clé - Dans n8n, après l’exécution de la requête HTTP, clique sur la sortie. Regarde le champ body dans la réponse. GHL retourne souvent {"succeded":true} ou un message d’erreur même sur des statuts 200.
2. Vérifie ton en-tête Authorization - GHL nécessite Bearer YOUR_ACCESS_TOKEN dans l’en-tête. Confirme aussi que tu utilises le bon jeton de localisation (pas le jeton d’agence) pour la création de contact.
3. Le nommage des champs est strict - L’API GHL pour les contacts utilise le camelCase exact : firstName, lastName, email, phone. Toute variation et le champ est silencieusement supprimé.
4. Assure-toi de frapper le bon endpoint - Pour créer/mettre à jour un contact, ce devrait être :
- POST
https://services.leadconnectorhq.com/contacts/ avec le payload de contact
Pourrais-tu partager une capture d’écran des paramètres du corps de ton nœud de requête HTTP et la sortie de réponse complète ? Cela m’aidera à identifier exactement où les données se perdent.
@wathoo
D’après la capture d’écran, la requête n’est pas encore authentifiée. Le nœud HTTP Request est défini sur Authentication: None, donc même si vous avez ajouté des lignes d’en-tête pour Authorization, Version et Content-Type, les valeurs semblent être vides. Je commencerais par corriger cela en envoyant les en-têtes GHL requis avec de vraies valeurs, en particulier le jeton Bearer, par exemple Authorization: Bearer <access_token>, la bonne Version d’API et Content-Type: application/json. Après cela, testez d’abord avec un corps minimal, tel que locationId, firstName, email et phone, puis rajoutez les champs restants une fois le contact créé avec succès.
