IBAN-Test integrieren

IBANs in n8n mit einer Workflow-Vorlage prüfen

Importieren Sie einen kleinen, manuell gestarteten Workflow, hinterlegen Sie Ihre IBAN-Test-API-Zugangsdaten und leiten Sie Prüfergebnisse in VALID- oder INVALID-Zweige. Die Vorlage prüft jeweils eine IBAN und stoppt, wenn kein verlässliches Prüfergebnis vorliegt.

Teststand des Beispiels: Der enthaltene Bericht dokumentiert 24 bestandene Offline-Prüfungen mit Node.js: JavaScript-Testfälle, Normalisierung, Duplikate, Grenzen, strikte Ergebnisklassifizierung, Zurückweisung widersprüchlicher Antworten sowie Workflow-Konfiguration und Verbindungen. Die Node-Definitionen wurden mit der offiziellen n8n-Dokumentation und dem Quellcode abgeglichen. Eine installierte n8n-Laufzeit und API-Zugangsdaten standen nicht zur Verfügung. Import, Ausführung in n8n, Zuordnung verknüpfter Elemente und authentifizierte API-Aufrufe sind daher noch ungeprüft. Führen Sie den unten beschriebenen manuellen Test in Ihrer Instanz durch, bevor Sie sich auf den Workflow verlassen.

Was die Vorlage macht

Nutzen Sie sie als Einstieg, bevor Sie ein Kundenformular, eine Tabelle oder eine interne Datenbank anbinden. Der Workflow startet manuell und enthält vier Beispielzeilen: eine veröffentlichte Beispiel-IBAN, eine Variante mit geänderter Prüfziffer, ein Duplikat und einen Leerwert. Er entfernt Leerraum, wandelt Buchstaben in Großbuchstaben um, überspringt leere Werte und gruppiert Duplikate. Die ursprünglichen Zeilenpositionen bleiben in sourceRows erhalten, sodass sich ein Ergebnis mehreren Zeilen zuordnen lässt.

Pro Durchlauf sind zehn unterschiedliche, nicht leere IBANs erlaubt. Bei mehr als zehn stoppt der Workflow vor der ersten Anfrage; überzählige Werte werden nicht stillschweigend verworfen. Fehlende oder leere Werte werden übersprungen, Werte ohne Zeichenkettentyp stoppen dagegen die Vorbereitung. Auch eine vollständig leere Eingabe führt zum Stopp. Speichern Sie IBANs in Ihrer Quelle als Text.

Für jede verbleibende IBAN erfolgt eine separate REST-Anfrage. Diese Integration verwendet keinen REST-Sammelendpunkt: Zehn unterschiedliche IBANs bedeuten bis zu zehn Prüfaufrufe. Die Duplikatbereinigung gilt innerhalb einer Ausführung. Ein erneuter Start prüft dieselben Werte erneut. Berücksichtigen Sie bei Ihrer Planung die IBAN-Test-API-Dokumentation.

1. Workflow-Datei importieren

Entpacken Sie die ZIP-Datei und öffnen Sie einen neuen Workflow in n8n. Wählen Sie im Drei-Punkte-Menü oben rechts Import from File und anschließend iban-test-n8n-workflow.json. Speichern Sie den Workflow unter einem aussagekräftigen Namen. Diese Schritte entsprechen der n8n-Anleitung zum Workflow-Import.

Es sollten neun Nodes erscheinen, beginnend mit Run manually. Der zentrale Node One IBAN at a time arbeitet mit einer Stapelgröße von eins. Sein loop-Ausgang führt zur HTTP-Anfrage und Klassifizierung; von dort geht es zurück zur Schleife. Sein done-Ausgang führt zu den Ergebniszweigen. Ändern Sie diese Verbindungen während des Tests nicht.

2. API-Token als Zugangsdaten hinterlegen

Öffnen Sie Validate IBAN. Die Authentifizierung ist als Generic Credential Type mit Header Auth eingerichtet. Legen Sie Header-Auth-Zugangsdaten mit folgenden Feldern an oder wählen Sie vorhandene aus:

• Name: Authorization
• Value: Bearer YOUR_API_TOKEN. Ersetzen Sie den Platzhalter durch Ihren Token und behalten Sie das Leerzeichen hinter Bearer bei.

Speichern und wählen Sie diese Zugangsdaten aus. Der Download enthält bewusst weder eine Zugangsdaten-ID noch ein Geheimnis. Hinterlegen Sie Ihren Token ausschließlich im Zugangsdatenformular, nicht im Beispielcode oder in gewöhnlichen Node-Parametern. Siehe die n8n-Referenz zu HTTP-Request-Zugangsdaten.

Die Anfrage ist bereits als POST https://www.iban-test.eu/api/v2/iban/validate konfiguriert. Der Ausdruck für den JSON-Body lautet {{ { iban: $json.iban } }}. Angefordert wird eine JSON-Antwort einschließlich HTTP-Status, damit der nächste Node sowohl Übertragung als auch API-Ergebnis prüfen kann. Die Einstellungen beschreibt die Dokumentation des HTTP-Request-Nodes.

3. Beispiele manuell ausführen

Öffnen Sie Sample rows und prüfen Sie die Beispielwerte. Starten Sie anschließend den gesamten Workflow über seinen manuellen Auslöser. Aus den vorgegebenen Zeilen entstehen zwei Anfrageelemente. Bei erfolgreicher API-Ausführung sollte das unveränderte Beispiel unter VALID results erscheinen, die Variante mit geänderter Prüfziffer unter INVALID results. Dies sind erwartete Ergebnisse Ihres ersten Live-Tests, keine Behauptung, der Download sei bereits mit einem authentifizierten Konto getestet worden.

Prüfen Sie bei jedem Ausgabeelement iban, sourceRows, status und code. Die Zweige enden derzeit in No-Operation-Nodes, an denen Sie Ergebnisse ansehen können, ohne in ein anderes System zu schreiben. Ersetzen Sie die Beispiele durch wenige freigegebene Testwerte, bevor Sie eine echte Datenquelle anbinden.

Prüfergebnisse und technische Fehler unterscheiden

Die Klassifizierung verlangt einen ganzzahligen numerischen Code und ein boolesches Fehlerfeld. Der Authentifizierungscode 4002, der Kontingentcode 4003 und der Code für gesperrten Zugang 4004 stoppen den Durchlauf. Ein Timeout, ein anderer HTTP-Status als 200 oder ein fehlerhafter Antwortinhalt wird niemals als ungültige IBAN erfasst. Grundlage sind die dokumentierten API-Ergebniscodes. Eine gültige IBAN belegt weder die Kontoinhaberschaft noch garantiert sie eine Zahlung.

Der Node Loop Over Items wartet auf die Klassifizierung, bevor er das nächste Element anfragt. Bei einem technischen Fehler werden spätere IBANs nicht mehr angefragt und die abschließenden Ergebniszweige nicht ausgeführt. Frühere Node-Ausgaben können im Editor weiterhin sichtbar sein. Behandeln Sie die Ausführung als unvollständig.

Automatische Wiederholungen sind deaktiviert. Beheben Sie Authentifizierungs- oder Kontingentprobleme vor dem Neustart. Ein manueller Neustart kann weitere Aufrufe für bereits geprüfte Zeilen verbrauchen. Falls Sie später Wiederholungen für vorübergehende Fehler ergänzen, begrenzen Sie Anzahl und Wartezeiten. Wiederholen Sie ungültige Eingaben oder Anfragen bei erschöpftem Kontingent niemals in einer Schleife.

Vor der Anbindung produktiver Daten

Die Vorlage deaktiviert das Speichern manueller, erfolgreicher und fehlgeschlagener Ausführungsdaten sowie des Fortschritts. Prüfen Sie diese Workflow-Einstellungen nach dem Import. IBANs und API-Antworten können während der Ausführung trotzdem sichtbar sein; auch Hosting-, Protokollierungs- und Sicherungsregeln spielen eine Rolle. Heften Sie keine echten Kundendaten an Nodes an und teilen Sie keine Workflow-Exporte, die solche Daten enthalten.

Verbinden Sie nach einem erfolgreichen manuellen Test jeden Ergebniszweig mit seinem vorgesehenen Ziel. Erhalten Sie Quellkennungen und verhindern Sie doppelte Datensätze bei wiederholten Durchläufen. Ergänzen Sie eine Zeitplanung erst, wenn Zeitzone, Kontingentbudget, Fehlermeldungen und Neustartverhalten feststehen.

Weitere Einstiege bieten die Anleitungen zur IBAN-Prüfung in Google Sheets und zur Prüfung einer IBAN-CSV mit Python.