Bonjour à tous,
J’appelle l’API Google Ads à partir du nœud HTTP Request car le nœud Google Ads natif ne supporte que « Get campaigns » et j’ai besoin d’autres points de terminaison.
Ma configuration :
- Nœud HTTP Request
- Authentication → Predefined Credential Type → Google Ads OAuth2 API (cela gère correctement le token OAuth Bearer)
Le problème : l’appel échoue avec DEVELOPER_TOKEN_PARAMETER_MISSING. Le nœud HTTP Request n’injecte pas automatiquement l’en-tête developer-token à partir de la credential Google Ads OAuth2, donc je dois l’ajouter manuellement.
Ce que j’ai essayé : j’ai ajouté un en-tête manuel developer-token et défini la valeur avec une expression pour que le token reste en dehors du JSON du workflow :
={{ $credentials.developerToken }}
Cela ne fonctionne pas pour moi. L’expression semble se résoudre en vide, donc le token est toujours manquant et j’obtiens la même erreur. Je soupçonne que $credentials n’est pas exposé dans les expressions du nœud HTTP Request pour des raisons de sécurité, mais je n’en suis pas sûr.
Mes questions :
- Y a-t-il un moyen supporté de référencer le developer-token à partir de la credential Google Ads OAuth2 existante dans le nœud HTTP Request, sans taper le token en ligne ? En ce moment, je le stocke dans une
$env, mais je veux m’en éloigner.
- Si
$credentials n’est pas disponible là, quelle est l’approche recommandée pour garder le token en dehors des exports de workflow ?
Je suis sur une instance auto-hébergée (Elestio). Merci d’avance pour vos conseils.
@jochem tu as raison, $credentials n’est pas exposé dans les expressions de nœud (seulement à l’intérieur des champs d’identification), donc cet en-tête se résout à vide, il n’y a pas de moyen supporté pour extraire le jeton de développement de la credential OAuth2 vers le nœud HTTP. garde OAuth2 pour l’authentification et définis la valeur de l’en-tête developer-token sur une variable à la place, {{ $vars.googleAdsDevToken }} sur cloud/enterprise (fonctionnalité Variables) ou {{ $env.GOOGLE_ADS_DEV_TOKEN }} auto-hébergé, pour que le jeton reste en dehors du JSON du workflow.
La syntaxe $credentials n’est pas accessible dans les expressions de valeur d’en-tête de requête HTTP. Cet objet n’est exposé que dans les définitions de type d’authentification personnalisé, pas dans les champs de nœud.
Pour n8n Cloud, l’approche la plus simple est d’utiliser les Variables n8n (Paramètres > Variables). Créez une variable (par exemple GOOGLE_ADS_DEV_TOKEN) et stockez votre jeton de développeur là. Puis dans le champ de valeur d’en-tête de la requête HTTP, utilisez :
{{ $vars.GOOGLE_ADS_DEV_TOKEN }}
Les variables ont une portée au niveau de l’espace de travail, n’apparaissent jamais dans le JSON du flux de travail exporté, et sont disponibles à partir du plan Starter et plus sur Cloud.
Si vous êtes auto-hébergé, l’alternative est une variable d’environnement. Définissez GOOGLE_ADS_DEV_TOKEN=xyz dans votre env Docker et référencez-la dans l’en-tête comme :
{{ $env.GOOGLE_ADS_DEV_TOKEN }}
L’accès à $env nécessite que N8N_BLOCK_ENV_ACCESS_IN_NODE=false (la valeur par défaut) soit actif. Sur Cloud, vous ne pouvez pas définir de variables d’environnement, donc Variables est la bonne approche.
À vérifier également : l’API Google Ads exige souvent un en-tête login-customer-id (l’ID client de votre MCC, sans tirets) sur les points de terminaison limités aux sous-comptes. L’absence de celui-ci est une deuxième cause d’erreur courante, aux côtés du jeton de développeur.
Salut à vous deux, merci pour vos réponses rapides. Ça fonctionne effectivement en auto-hébergé en utilisant une variable $env. J’ai toujours utilisé cette approche jusqu’à présent.
J’ai récemment mis à niveau vers n8n v2 et j’ai l’impression que l’utilisation de la variable $env est déconseillée pour des raisons de sécurité. C’est pourquoi j’étais curieux de savoir si quelqu’un connaissait une meilleure alternative pour les environnements auto-hébergés.
Pour l’instant, je vais continuer avec N8N_BLOCK_ENV_ACCESS_IN_NODE=false.
Je serais ravi d’entendre parler de meilleures alternatives 
@jochem $env avec N8N_BLOCK_ENV_ACCESS_IN_NODE=false est vraiment l’approche prévue sur la version communautaire auto-hébergée, le blocage par défaut est juste une protection contre les workflows qui liraient accidentellement les variables d’environnement de l’hôte, autoriser délibérément un secret connu n’est pas mal. la seule option intégrée plus sécurisée est External Secrets ($secrets, s’intègre avec Vault / AWS / Azure / GCP secrets managers), mais c’est réservé à la version Enterprise auto-hébergée. donc sur la version communautaire, il n’y a pas de meilleure alternative, tu peux continuer à utiliser l’approche $env sans problème.
Vous l’avez diagnostiqué correctement — $credentials n’est intentionnellement pas exposé dans les expressions de nœud, donc {{
$credentials.developerToken }} se résout à vide. Et le nœud HTTP Request n’injecte que le Bearer OAuth2 de la credential Google Ads, pas le champ developer-token — il n’y a pas de toggle pour le transmettre, et vous ne pouvez pas attacher une seconde credential prédéfinie. Le token doit donc provenir de quelque part qui soit référençable.
Options pour le tenir en dehors de l’export du workflow :
- $env est en fait une approche supportée — elle maintient bien le token en dehors du JSON du workflow, donc y rester n’est pas faux, juste moins pratique.
- n8n Variables ({{ $vars.googleAdsDeveloperToken }}) — même effet mais géré dans l’interface plutôt que dans env, si votre plan supporte les Variables.
- Le vrai fix avec une seule credential : construire un petit type de credential personnalisé qui étend la credential OAuth2 Google Ads pour aussi injecter developer-token (et login-customer-id) en tant que header dans son bloc authenticate. Alors une seule Credential Prédéfinie gère Bearer et dev-token, le nœud HTTP Request n’a besoin d’aucun header manuel, et rien ne se retrouve dans l’export. Vous êtes autohébergé sur Elestio, donc vous pouvez déposer une credential personnalisée — c’est la réponse la plus propre à long terme et vous donne exactement le comportement « le référencer depuis la credential, pas inline » que vous recherchez.
Réponse : Non, il n’existe pas de méthode prise en charge pour accéder aux champs de données d’identification (credentials) à partir d’expressions du nœud HTTP Request. Les données d’identification sont utilisées uniquement pour l’authentification (OAuth2) et ne sont pas exposées aux expressions, donc vous ne pouvez pas écrire :Réponse : Non, il n’existe pas de méthode prise en charge pour accéder aux champs de données d’identification (credentials) à partir d’expressions du nœud HTTP Request. Les données d’identification sont utilisées uniquement pour l’authentification (OAuth2) et ne sont pas exposées aux expressions, donc vous ne pouvez pas écrire :