Hola a todos,
Estoy llamando a la API de Google Ads desde el nodo HTTP Request porque el nodo nativo de Google Ads solo admite “Obtener campañas” y necesito otros endpoints.
Mi configuración:
- Nodo HTTP Request
- Autenticación → Tipo de credencial predefinido → Google Ads OAuth2 API (esto maneja correctamente el token Bearer de OAuth)
El problema: la llamada falla con DEVELOPER_TOKEN_PARAMETER_MISSING. El nodo HTTP Request no inyecta automáticamente el header developer-token de la credencial OAuth2 de Google Ads, así que tengo que agregarlo manualmente.
Lo que intenté: agregué un header manual developer-token y establecí el valor con una expresión para que el token se mantenga fuera del JSON del flujo:
={{ $credentials.developerToken }}
Esto no funciona para mí. La expresión parece resolverse como vacía, así que el token sigue faltando y obtengo el mismo error. Mi suposición es que $credentials no está expuesto dentro de las expresiones del nodo HTTP Request por razones de seguridad, pero no estoy seguro.
Mis preguntas:
- ¿Hay una forma soportada de referenciar el developer-token de la credencial OAuth2 de Google Ads existente dentro del nodo HTTP Request, sin escribir el token en línea? Actualmente lo estoy almacenando en un
$env, pero quiero dejar de usar eso.
- Si
$credentials no está disponible allí, ¿cuál es el enfoque recomendado para mantener el token fuera de las exportaciones de flujo?
Estoy en una instancia autohospedada (Elestio). Gracias de antemano por cualquier ayuda.
@jochem tienes razón, $credentials no se expone en expresiones de nodos (solo dentro de campos de credenciales), por lo que ese encabezado se resuelve vacío, no hay una forma compatible para extraer el token de desarrollo de la credencial OAuth2 hacia el nodo HTTP. mantén OAuth2 para la autenticación y establece el valor del encabezado developer-token en una variable en su lugar, {{ $vars.googleAdsDevToken }} en cloud/enterprise (función Variables) o {{ $env.GOOGLE_ADS_DEV_TOKEN }} auto-hospedado, para que el token permanezca fuera del JSON del flujo de trabajo.
El atajo $credentials no es accesible en expresiones de valores de encabezados HTTP Request. Ese objeto solo se expone dentro de definiciones de tipos de credenciales personalizadas, no en campos de nodos.
Para n8n Cloud, el enfoque más limpio es Variables de n8n (Settings > Variables). Crea una variable (por ejemplo, GOOGLE_ADS_DEV_TOKEN) y almacena tu token de desarrollador allí. Luego, en el campo de valor del encabezado HTTP Request usa:
{{ $vars.GOOGLE_ADS_DEV_TOKEN }}
Las variables tienen alcance de espacio de trabajo, nunca aparecen en el JSON del flujo de trabajo exportado, y están disponibles en el plan Starter y superior en Cloud.
Si tienes un servidor autohospedado, la alternativa es una variable de entorno. Establece GOOGLE_ADS_DEV_TOKEN=xyz en tu entorno Docker y haz referencia a ella en el encabezado como:
{{ $env.GOOGLE_ADS_DEV_TOKEN }}
El acceso a $env requiere que N8N_BLOCK_ENV_ACCESS_IN_NODE=false (el valor predeterminado) esté activo. En Cloud no puedes establecer variables de entorno, así que Variables es la opción correcta.
También vale la pena verificar: la API de Google Ads a menudo requiere un encabezado login-customer-id (tu ID de cliente MCC, sin guiones) en puntos finales con alcance de subcuentas. La falta de esto es una segunda causa común de errores junto con el token de desarrollador.
Hola a ambos, gracias por sus respuestas rápidas. Efectivamente funciona en auto-hospedado usando una variable $env. Siempre he usado este enfoque hasta ahora.
Recientemente actualicé a n8n v2 y tengo la impresión de que el uso de la variable $env está desaconsejado por razones de seguridad. Por eso tenía curiosidad de saber si alguien conoce una alternativa mejor para entornos auto-hospedados.
Por ahora, procederé con N8N_BLOCK_ENV_ACCESS_IN_NODE=false.
Me encantaría escuchar sobre alternativas mejores 
@jochem $env con N8N_BLOCK_ENV_ACCESS_IN_NODE=false es genuinamente el enfoque previsto en self-hosted comunitario, el bloqueo predeterminado es solo una protección contra flujos de trabajo que leen accidentalmente variables de entorno del host, permitir deliberadamente una variable secreta conocida no está mal. la única opción integrada más segura es External Secrets ($secrets, se integra con Vault / AWS / Azure / GCP secret managers), pero eso es solo para self-hosted Enterprise. así que en community no hay una alternativa mejor, está bien que sigas usando el enfoque $env.
Lo has diagnosticado correctamente — $credentials no se expone intencionalmente en expresiones de nodos, por lo que {{ $credentials.developerToken }} se resuelve en vacío. Y el nodo HTTP Request solo inyecta el Bearer OAuth2 de la credencial de Google Ads, no el campo developer-token — no hay un toggle para pasarlo, y no puedes adjuntar una segunda credencial predefinida. Así que el token tiene que venir de algún lugar referenciable.
Opciones para mantenerlo fuera de la exportación del flujo de trabajo:
- $env es en realidad un enfoque soportado — sí mantiene el token fuera del JSON del flujo de trabajo, así que quedarse ahí no es incorrecto, solo menos conveniente.
- Variables de n8n ({{ $vars.googleAdsDeveloperToken }}) — mismo efecto pero gestionado en la UI en lugar de env, si tu plan tiene Variables.
- La solución correcta de una credencial: construir un tipo de credencial personalizada pequeña que extienda la credencial OAuth2 de Google Ads para también inyectar developer-token (y login-customer-id) como encabezado en su bloque authenticate. Entonces una única Credencial Predefinida maneja Bearer y dev-token, el nodo HTTP Request no necesita encabezado manual, y nada llega a la exportación. Estás auto-hospedado en Elestio, así que puedes soltar una credencial personalizada — es la respuesta más limpia a largo plazo y te da exactamente el comportamiento de “referenciarla desde la credencial, sin inline” que buscas.
Respuesta: No, no hay una forma compatible para acceder a los campos de datos de credenciales (credentials) desde dentro de expresiones de nodo HTTP Request. Las credenciales se utilizan solo para autenticación (OAuth2) y no se exponen a las expresiones, por lo que no puedes escribir:Respuesta: No, no hay una forma compatible para acceder a los campos de datos de credenciales (credentials) desde dentro de expresiones de nodo HTTP Request. Las credenciales se utilizan solo para autenticación (OAuth2) y no se exponen a las expresiones, por lo que no puedes escribir: