n8n Credentials einrichten und sicher zuordnen

Was ein Credential verbindet

Ein Credential stellt einem n8n-Node die Zugangsdaten für einen externen Dienst bereit, etwa für eine API oder Datenbank. Prüfe zusätzlich den ausgewählten Node und die API-Adresse: Auch ein gültiger Schlüssel kann am falschen Ziel oder für eine nicht erlaubte Aktion eingesetzt werden.

Der Zugang des Webhook-Senders sitzt an einer anderen Stelle: Er schützt den eingehenden Aufruf von n8n. Das zeigt die Anleitung zum n8n-Webhook mit Test- und Produktions-URL. Ein Credential für eine nachgelagerte API authentifiziert diesen Sender nicht automatisch.

Credential anlegen und eindeutig benennen

Klicke auf Create → Credential, wähle den Dienst und fülle die benötigten Felder aus. Direkt im Workflow geht das auch über die Credential-Auswahl im Node. Die Herstelleranleitung zeigt beide Wege.

1. Bestimme, welcher Dienst und welches Konto für den Workflow vorgesehen sind.
2. Lege den passenden Credential-Typ an und trage die Angaben aus der Dokumentation dieses Dienstes ein.
3. Gib dem Zugang einen erkennbaren Namen. Unser Beispiel Test · Lager · Lesen benennt Umgebung, Zweck und vorgesehenen Umfang; der Name setzt selbst keine Rechte.
4. Speichere das Credential und wähle es im vorgesehenen Node aus.

Wenn deine Instanz Projekte unterstützt, prüfe beim Anlegen den gewählten Raum. Ein ähnlicher Name allein beweist nicht, dass ein importierter Node auf den richtigen gespeicherten Zugang verweist.

Das Verfahren der API übernehmen

Wähle für dein Credential das Anmeldeverfahren, das die API-Dokumentation des Dienstes vorgibt – etwa Basic Auth, Header Auth oder OAuth2. Im HTTP Request-Node nutzt du unter Authentication einen passenden Predefined Credential Type, wenn es ihn für deinen Dienst gibt. Andernfalls richtest du ein generisches Credential nach den API-Vorgaben ein. Die HTTP-Credential-Referenz zeigt die benötigten Felder.

Ein eigener fiktiver API-Vertrag könnte den Header X-Lager-Key verlangen. Dann ist dies der Name im Header-Auth-Credential; der vom Dienst ausgestellte geheime Schlüssel wird dessen Value. DEIN_API_SCHLUESSEL ist nur ein Platzhalter, kein verwendbarer Zugang. Übernimm diesen Headernamen nicht für einen anderen Dienst, dessen Dokumentation etwas anderes fordert.

Zugriff auf den vorgesehenen Dienst begrenzen

Wähle unter Allowed HTTP Request Domains die Option Specific Domains und trage die erlaubten API-Domains ein. Der HTTP Request-Node darf dieses Credential dann nur für diese Domains verwenden. Mehrere Domains trennst du mit Kommas; None sperrt die Nutzung dieses Credentials im HTTP Request-Node vollständig. Das Feld ist nicht bei jedem Credential vorhanden und begrenzt keine Aufrufe über den jeweiligen dedizierten Dienst-Node.

Für den Betrieb schlagen wir vor: einen gesonderten Testzugang verwenden, nur die benötigten Rechte beim Anbieter freigeben und den tatsächlichen Host jedes Requests vor dem Test kontrollieren. Eine Leseberechtigung passt zu einer Leseaufgabe; die Benennung des Credentials ersetzt die Rechtevergabe beim Anbieter nicht.

Dynamische Credentials bewusst einsetzen

Schalte ein unterstütztes Token- oder API-Key-Feld im Credential auf Expression und lies den Zugangswert aus einem vorher ausgeführten Node. Für Test und Produktion setzt du mit Edit Fields (Set) eine Umgebungskennung wie test oder prod; ein vorgeschalteter Sub-Workflow liefert den dafür freigegebenen Wert.

1. Umgebung setzen: Lege vor dem API-Aufruf im Edit-Fields-Node das Textfeld env an. Setze die Kennung im kontrollierten Start-Workflow fest; echte API-Schlüssel gehören nicht als feste Werte in diesen Set-Node.
2. Wert bereitstellen: Ein Unterworkflow mit When Executed by Another Workflow nimmt env entgegen und liefert nach freigegebener Zuordnung genau ein Item mit token zurück. Das Laden des echten Tokens musst du an deine geschützte Konfiguration anpassen.
3. Unterworkflow aufrufen: Verwende im Hauptworkflow Execute Sub-workflow, übergib env und nenne diesen Aufruf-Node Get Env. Aktiviere Wait for Sub-Workflow Completion, damit der Wert vor dem API-Schritt vorliegt.
4. Credential verknüpfen: Öffne das unterstützte Token- oder API-Key-Feld des Credentials, schalte auf Expression und trage den folgenden Ausdruck ein. Wähle dieses Credential anschließend im nachgelagerten Dienst- oder HTTP-Request-Node aus.

{{ $('Get Env').first().json.token }}

Get Env bezeichnet hier den Aufruf-Node im Hauptworkflow. first() liest dessen erstes Ausgabe-Item. Das Beispiel setzt einen einzigen passenden Aufruf mit genau einem Zugangswert voraus; bei mehreren Nutzern oder Items brauchst du eine gezielte Zuordnung. Prüfe beide Umgebungen mit einer geeigneten lesenden Anfrage und kontrolliere Dienst und Konto.

Geltungsbereich: Dieses Muster befüllt unterstützte Credential-Felder zur Laufzeit. Prüfe im Editor, ob das konkrete Feld Expressions anbietet. Ein Trigger kann noch nicht auf einen erst danach ausgeführten Get Env-Node zugreifen. Eine extern übergebene Kennung prod ersetzt keine Freigabe für den Produktionszugang.

Ausführungsdaten beachten: Der Token läuft bei diesem Muster durch Node-Ausgaben und kann in gespeicherten Ausführungsdaten stehen. Prüfe daher Zugriffsrechte und Speicherregeln, bevor du echte Secrets so verarbeitest. Das ist eine Beispielstruktur, kein hier ausgeführter n8n-Test.

Die Template-Beschreibung zeigt das Grundprinzip mit einer Formulareingabe und einem NASA-Node. Ein Eingabefeld bestätigt keine Identität oder Berechtigung. Die Test-/Prod-Struktur greift die Idee des Reddit-Beitrags von 2025 auf; pauschale Funktionszusagen für alle Nodes lassen sich daraus nicht ableiten.

Für einen kleinen internen Einstieg bleibt ein fest zugeordnetes Credential der einfachere Weg. Die separaten End-user credentials für OAuth sind auf n8n Cloud Enterprise und Self-hosted Enterprise verfügbar; die aktuelle Doku kennzeichnet sie als Preview und rät vom produktiven Einsatz ab.

Die Grundlagen zu n8n Expressions und Item-Auswahl erklären, wie ein Datenpfad zum richtigen Eingabe-Item passt.

Verschlüsselung und Wiederherstellung einplanen

Sichere bei selbst gehostetem n8n für die Wiederherstellung die Datenbank und den zugehörigen Verschlüsselungsschlüssel. Ohne den passenden Schlüssel kann n8n die gespeicherten Credentials nicht entschlüsseln. Standardmäßig erzeugt n8n ihn beim ersten Start und speichert ihn in ~/.n8n. Bei der Einrichtung kannst du ihn stattdessen über N8N_ENCRYPTION_KEY vorgeben; im Queue-Betrieb müssen die Worker denselben Schlüssel wie die Hauptinstanz verwenden. Das beschreibt die Originalreferenz.

Dieser Instanzschlüssel ist kein API-Token für deinen Lagerdienst. Bewahre ihn für eine Wiederherstellung zusammen mit den benötigten gesicherten Instanzdaten auf. Ändere ihn in einer bestehenden Installation nicht beiläufig nach einer Einrichtungsanleitung für neue Instanzen.

Ein exportierter Workflow allein ist kein Nachweis, dass auch gespeicherte Credentials und ihre Entschlüsselung wiederhergestellt werden können. Plane den Umzug nach deiner Installations- und Datenbankart und prüfe die Wiederherstellung getrennt vom produktiven Betrieb. Die Grafik beschreibt nur die Beziehung, kein fertiges Backupverfahren.

Den tatsächlichen Request prüfen

Die Dokumentation beschreibt einen Test beim Speichern von Credentials. Das ersetzt keine Prüfung deiner konkreten Workflow-Aufgabe. Unser vorgeschlagenes Prüfprotokoll:

• Ziel: Richtiger Dienst, Testumgebung und dokumentierter Endpunkt.
• Zuordnung: Im Node ist das dafür vorgesehene Credential ausgewählt.
• Operation: Eine geeignete lesende Anfrage für den Test; keine unbeabsichtigte Änderung.
• Befund: Antwort und benötigte Daten prüfen, ohne Secret-Werte in den Bericht zu kopieren.

Bei einem Import prüfst du die Zuordnung erneut. Bei einer abgewiesenen Anfrage vergleichst du Auth-Verfahren und Anbieterrechte; bei einem Verbindungsfehler zuerst Adresse und Erreichbarkeit. Halte den Fehlerbefund fest und ändere jeweils nur einen Teil der Konfiguration. Hier wurde keine n8n-Instanz verbunden und kein echter API-Schlüssel ausprobiert. Der Guide zum n8n HTTP Request zeigt, wie du Methode, Authentifizierung und Antwort separat prüfst.

401, 403 oder Verbindungsfehler unterscheiden

Grenze zuerst ein, ob du überhaupt eine HTTP-Antwort des vorgesehenen Dienstes erhalten hast. Tausche nicht gleichzeitig URL, Auth-Typ und Schlüssel aus; sonst lässt sich eine Veränderung schwer zuordnen.

Die HTTP-Referenzen zu 401 Unauthorized und 403 Forbidden erklären die grundsätzliche Unterscheidung zwischen fehlender gültiger Anmeldung und verweigertem Zugriff. Einzelne APIs können zusätzliche Regeln haben. Lies deshalb auch deren bereinigte Fehlermeldung.

Für eine Rückfrage genügen meist Node-Typ, n8n-Version, verwendetes Auth-Verfahren, Statuscode und ein bereinigter Fehlertext. Entferne geheime Headerwerte, Cookies und private Nutzdaten. Eine solche Beschreibung ist auch hilfreicher als ein vollständiger Request-Dump mit unbekanntem Inhalt.

Diagnose-Prüfzettel als Textdatei herunterladen ↓