Estou chamando a Google Ads API a partir do nó HTTP Request porque o nó nativo Google Ads apenas suporta “Get campaigns” e preciso de outros endpoints.
Minha configuração:
Nó HTTP Request
Autenticação → Tipo de Credencial Predefinida → Google Ads OAuth2 API (isso funciona bem com o token Bearer OAuth)
O problema: a chamada falha com DEVELOPER_TOKEN_PARAMETER_MISSING. O nó HTTP Request não injeta automaticamente o header developer-token da credencial Google Ads OAuth2, então tenho que adicioná-lo manualmente.
O que tentei: adicionei um header manual developer-token e defini o valor com uma expressão para que o token não fique no JSON do workflow:
={{ $credentials.developerToken }}
Isso não funciona para mim. A expressão parece resolver para vazio, então o token continua faltando e recebo o mesmo erro. Meu palpite é que $credentials não é exposto dentro das expressões do nó HTTP Request por razões de segurança, mas não tenho certeza.
Minhas perguntas:
Existe uma forma suportada de referenciar o developer-token da credencial Google Ads OAuth2 existente dentro do nó HTTP Request, sem digitar o token inline? No momento estou armazenando em uma $env, mas quero deixar de usar isso.
Se $credentials não está disponível ali, qual é a abordagem recomendada para manter o token fora das exportações de workflow?
Estou em uma instância auto-hospedada (Elestio). Obrigado antecipadamente por qualquer orientação.
@jochem você está certo, $credentials não é exposto em expressões de nó (apenas dentro de campos de credencial), então esse header resolve como vazio, não há uma forma suportada de extrair o token de desenvolvimento da credencial OAuth2 para o nó HTTP. mantenha OAuth2 para autenticação e defina o valor do header developer-token para uma variável em vez disso, {{ $vars.googleAdsDevToken }} em cloud/enterprise (recurso de Variáveis) ou {{ $env.GOOGLE_ADS_DEV_TOKEN }} auto-hospedado, para que o token fique fora do JSON do workflow.
O atalho $credentials não é acessível em expressões de valor de cabeçalho de requisição HTTP. Esse objeto é exposto apenas dentro de definições de tipo de credencial personalizado, não em campos de nó.
Para n8n Cloud, a abordagem mais limpa é usar n8n Variables (Configurações > Variáveis). Crie uma variável (por exemplo, GOOGLE_ADS_DEV_TOKEN) e armazene seu token de desenvolvedor lá. Em seguida, no campo de valor do cabeçalho da requisição HTTP, use:
{{ $vars.GOOGLE_ADS_DEV_TOKEN }}
As variáveis têm escopo de workspace, nunca aparecem no JSON do workflow exportado e estão disponíveis no plano Starter e superiores na Cloud.
Se você está usando auto-hospedagem, a alternativa é uma variável de ambiente. Defina GOOGLE_ADS_DEV_TOKEN=xyz no seu env do Docker e faça referência no cabeçalho como:
{{ $env.GOOGLE_ADS_DEV_TOKEN }}
O acesso a $env requer que N8N_BLOCK_ENV_ACCESS_IN_NODE=false (o padrão) esteja ativo. Na Cloud você não pode definir variáveis de ambiente, então Variables é o caminho correto.
Além disso, vale a pena verificar: a API do Google Ads frequentemente requer um cabeçalho login-customer-id (seu ID de cliente MCC, sem hífens) em endpoints com escopo de subconta. Essa é uma segunda causa comum de erros, junto com o token de desenvolvedor.
Oi para vocês dois, obrigado pelas respostas rápidas. De fato funciona em self-hosted usando uma variável $env. Eu sempre usei essa abordagem até agora.
Recentemente atualizei para n8n v2 e tenho a impressão de que usar a variável $env é desencorajado por motivos de segurança. É por isso que fiquei curioso para saber se alguém conhece uma alternativa melhor para ambientes self-hosted.
Por enquanto, vou prosseguir com N8N_BLOCK_ENV_ACCESS_IN_NODE=false.
Ficaria feliz em ouvir sobre alternativas melhores
@jochem $env com N8N_BLOCK_ENV_ACCESS_IN_NODE=false é genuinamente a abordagem pretendida no self-hosted da comunidade, o bloqueio padrão é apenas uma proteção contra workflows lendo acidentalmente variáveis de ambiente do host, permitir deliberadamente isso para um único secret conhecido não está errado. a única opção mais segura integrada é External Secrets ($secrets, integra com Vault / AWS / Azure / GCP secrets managers), mas isso é apenas para self-hosted Enterprise. então na comunidade não há alternativa melhor, você pode ficar tranquilo usando a abordagem $env.
Você diagnosticou corretamente — $credentials não é intencionalmente exposto em expressões de nó, portanto {{ $credentials.developerToken }} resolve para vazio. E o nó HTTP Request apenas injeta o Bearer OAuth2 da credencial do Google Ads, não o campo developer-token — não há um botão para passar, e você não pode anexar uma segunda credencial predefinida. Então o token precisa vir de algum lugar referenciável.
Opções para mantê-lo fora da exportação do fluxo de trabalho:
$env é na verdade uma abordagem suportada — ela mantém o token fora do JSON do fluxo de trabalho, portanto ficar lá não está errado, apenas menos conveniente.
n8n Variables ({{ $vars.googleAdsDeveloperToken }}) — mesmo efeito, mas gerenciado na UI em vez de env, se seu plano tiver Variables.
O reparo adequado de uma credencial: construa um pequeno tipo de credencial personalizado que estenda a credencial OAuth2 do Google Ads para também injetar developer-token (e login-customer-id) como um header em seu bloco authenticate. Então uma única Credencial Predefinida lida com Bearer e dev-token, o nó HTTP Request não precisa de header manual, e nada vai para a exportação. Você está auto-hospedado no Elestio, então pode adicionar uma credencial personalizada — é a resposta mais limpa a longo prazo e oferece exatamente o comportamento “referencie da credencial, sem inline” que você procura.
Resposta: Não, não há uma forma suportada para acessar campos de dados de credenciais (credentials) de dentro de expressões de nó HTTP Request. As credenciais são usadas apenas para autenticação (OAuth2) e não são expostas para as expressões, portanto você não pode escrever:Resposta: Não, não há uma forma suportada para acessar campos de dados de credenciais (credentials) de dentro de expressões de nó HTTP Request. As credenciais são usadas apenas para autenticação (OAuth2) e não são expostas para as expressões, portanto você não pode escrever:
