Hallo zusammen,
Ich rufe die Google Ads API vom HTTP Request Node aus auf, weil der native Google Ads Node nur „Get campaigns
@jochem du hast recht, $credentials wird in Node-Ausdrücken nicht exponiert (nur innerhalb von Credential-Feldern), daher wird dieser Header leer aufgelöst, es gibt keine unterstützte Möglichkeit, das Dev-Token aus der OAuth2-Anmeldedaten in den HTTP-Node zu übernehmen. Behalte OAuth2 für die Authentifizierung bei und setze den Headerwert des Developer-Tokens stattdessen auf eine Variable, {{ $vars.googleAdsDevToken }} auf Cloud/Enterprise (Variables-Funktion) oder {{ $env.GOOGLE_ADS_DEV_TOKEN }} selbstgehostet, damit das Token außerhalb der Workflow-JSON bleibt.
Die $credentials-Kurzform ist in HTTP-Request-Header-Wertausdrücken nicht zugänglich. Dieses Objekt wird nur in benutzerdefinierten Credential-Typ-Definitionen offengelegt, nicht in Node-Feldern.
Für n8n Cloud ist der sauberste Ansatz n8n Variables (Settings > Variables). Erstelle eine Variable (z. B. GOOGLE_ADS_DEV_TOKEN) und speichere dort deinen Developer Token. Verwende dann im HTTP-Request-Header-Wertfeld:
{{ $vars.GOOGLE_ADS_DEV_TOKEN }}
Variablen sind Workspace-Bereich, erscheinen nie in exportierten Workflow-JSON und sind ab dem Starter-Plan auf Cloud verfügbar.
Wenn du selbst gehostet bist, ist die Alternative eine Umgebungsvariable. Setze GOOGLE_ADS_DEV_TOKEN=xyz in deiner Docker-Umgebung und referenziere sie im Header wie folgt:
{{ $env.GOOGLE_ADS_DEV_TOKEN }}
$env-Zugriff erfordert, dass N8N_BLOCK_ENV_ACCESS_IN_NODE=false (der Standard) aktiv ist. Auf Cloud kannst du keine Umgebungsvariablen setzen, daher ist Variables der richtige Weg.
Es ist auch sinnvoll zu überprüfen: Die Google Ads API erfordert oft einen login-customer-id-Header (deine MCC-Kundennummer, ohne Bindestriche) auf Sub-Account-bezogenen Endpoints. Dies zu vergessen ist neben dem Developer Token eine häufige zweite Fehlerursache.
Hallo zusammen, danke für eure schnellen Antworten. Es funktioniert tatsächlich im Self-Hosted-Modus mit einer $env-Variable. Ich habe diesen Ansatz bisher immer verwendet.
Ich bin kürzlich auf n8n v2 aktualisiert und habe den Eindruck, dass die Verwendung der $env-Variable aus Sicherheitsgründen nicht empfohlen wird. Deshalb war ich neugierig, ob jemand eine bessere Alternative für Self-Hosted-Umgebungen kennt.
Vorerst werde ich mit N8N_BLOCK_ENV_ACCESS_IN_NODE=false weitermachen.
Ich würde mich freuen, von besseren Alternativen zu hören 
@jochem $env mit N8N_BLOCK_ENV_ACCESS_IN_NODE=false ist genuinely der beabsichtigte Ansatz auf Community Self-Hosted, die Standard-Blockierung ist nur ein Schutz davor, dass Workflows versehentlich Host-Umgebungsvariablen auslesen, und es ist nicht falsch, sie bewusst für ein bekanntes Secret freizugeben. Die einzige sicherere Built-in-Option ist External Secrets ($secrets, integriert mit Vault / AWS / Azure / GCP Secrets Manager), aber das ist nur für Enterprise Self-Hosted verfügbar. Also gibt es auf Community keine bessere Alternative, du machst es richtig, bei dem $env-Ansatz zu bleiben.
Du hast es richtig diagnostiziert — $credentials wird absichtlich nicht in Node-Ausdrücken offengelegt, daher wird {{ $credentials.developerToken }} zu leer aufgelöst. Und der HTTP Request Node injiziert nur das OAuth2 Bearer-Token von der Google Ads-Anmeldedaten, nicht das Feld developer-token — es gibt keinen Schalter, um es weiterzuleiten, und du kannst keine zweite vordefinierte Anmeldedaten anhängen. Das Token muss also von irgendwo kommen, das referenzierbar ist.
Optionen, um es aus dem Workflow-Export herauszuhalten:
- $env ist tatsächlich ein unterstützter Ansatz — es hält das Token aus der Workflow-JSON heraus, also dort zu bleiben ist nicht falsch, nur weniger komfortabel.
- n8n-Variablen ({{ $vars.googleAdsDeveloperToken }}) — gleicher Effekt, aber in der Benutzeroberfläche statt in env verwaltet, falls dein Plan über Variablen verfügt.
- Die eigentliche Einzel-Anmeldedaten-Lösung: Erstelle einen kleinen benutzerdefinierten Anmeldedatentyp, der die Google Ads OAuth2-Anmeldedaten erweitert, um developer-token (und login-customer-id) auch als Header in seinem authenticate-Block zu injizieren. Dann verwaltet eine einzige vordefinierte Anmeldedaten Bearer und Dev-Token, der HTTP Request Node benötigt keinen manuellen Header, und nichts landet im Export. Du bist Self-Hosted auf Elestio, also kannst du eine benutzerdefinierte Anmeldedaten einbinden — das ist die sauberste langfristige Lösung und gibt dir genau das Verhalten „referenziere es von den Anmeldedaten, kein Inline", das du dir wünschst.
Die Antwort: Nein, es gibt keine unterstützte Möglichkeit, auf Credential-Felder (Anmeldedaten) aus Ausdrücken im HTTP Request-Knoten zuzugreifen. Anmeldedaten werden nur für die Authentifizierung (OAuth2) verwendet und werden nicht für Ausdrücke offengelegt, daher kannst du nicht schreiben:Die Antwort: Nein, es gibt keine unterstützte Möglichkeit, auf Credential-Felder (Anmeldedaten) aus Ausdrücken im HTTP Request-Knoten zuzugreifen. Anmeldedaten werden nur für die Authentifizierung (OAuth2) verwendet und werden nicht für Ausdrücke offengelegt, daher kannst du nicht schreiben: