IBAN-Test integration guide
Validate IBANs in n8n with a downloadable workflow
Import a small manual workflow, connect your IBAN-Test API credential, and route IBAN validation results to VALID or INVALID branches. The starter checks one IBAN at a time and stops when it cannot obtain a reliable validation result.
The ZIP contains the workflow JSON, setup instructions, an offline validation script and its report. You need an n8n instance that supports the included core nodes, permission to create credentials, and an IBAN-Test API token with available quota.
What the starter does
Use this as a first step before connecting a customer form, spreadsheet or internal database. The workflow starts manually and contains four example rows: a published example IBAN, a changed-checksum version, a duplicate and a blank. It removes whitespace, converts letters to uppercase, skips empty values and groups duplicates. The original row positions remain in sourceRows, so one result can be mapped back to several rows.
The limit is ten distinct, nonempty IBANs per run. More than ten stops the workflow before any request; it does not silently discard the remainder. Missing or blank values are skipped, while a non-string value stops preparation. An entirely empty input also stops. Keep IBANs as text in your source.
Each remaining IBAN goes through a separate REST request. There is no REST bulk endpoint in this integration: ten distinct IBANs mean up to ten validation calls. Deduplication applies within one execution, so running the workflow again checks those values again. Consult the IBAN-Test API documentation when planning usage.
1. Import the workflow file
Extract the ZIP and open a new workflow in n8n. Use the three-dot menu in the upper-right corner, choose Import from File, and select iban-test-n8n-workflow.json. Save it under a name you recognise. These steps follow n8n’s workflow import documentation.
You should see nine nodes, beginning with Run manually. The central One IBAN at a time node uses a batch size of one. Its loop output leads to the HTTP request and classifier; the classifier returns to the loop. Its done output leads to the result branches. Do not change that wiring while testing the starter.
2. Add the API token as a credential
Open Validate IBAN. Authentication is configured as Generic Credential Type, with Header Auth. Create or select a Header Auth credential with these fields:
- Name:
Authorization - Value:
Bearer YOUR_API_TOKEN, replacing the placeholder with your actual token and keeping the space afterBearer.
Save and select that credential. The download deliberately has no credential ID or secret. Keep your token in the credential form; do not add it to the sample code or ordinary node parameters. See n8n’s HTTP Request credentials reference.
The request is already configured as POST https://www.iban-test.eu/api/v2/iban/validate. Its JSON body expression is {{ { iban: $json.iban } }}. It requests a JSON response and includes the HTTP status, allowing the next node to inspect both transport and API results. The relevant controls are explained in the HTTP Request node documentation.
3. Run the examples manually
Open Sample rows to review the example values, then execute the whole workflow from its manual trigger. The supplied rows reduce to two request items. On a successful API run, the unchanged example should reach VALID results and the changed-checksum example should reach INVALID results. Those are expected outcomes for your first live check, not a claim that this download has been tested with an authenticated account.
Inspect each output item’s iban, sourceRows, status and code. The branches currently end in No Operation nodes, providing inspection points without writing to another system. Replace the samples with a few authorised test values before connecting a real data source.
How results and failures are separated
| Response | Workflow action |
|---|---|
HTTP 200, code 2100, error: false | Return VALID. |
HTTP 200, code 3100, 3101 or 3102, error: true | Return INVALID for correction. |
| Any other code, failed request or unexpected response | Stop execution for investigation. |
The classifier requires a numeric integer code and a Boolean error field. Authentication code 4002, quota code 4003, and disabled-access code 4004 stop the run. A timeout, non-200 response or malformed body is never recorded as an invalid IBAN. These distinctions follow the documented API result codes. A valid IBAN does not establish account ownership or guarantee a payment.
The Loop Over Items node waits for classification before requesting the next item. If a technical failure occurs, later IBANs are not requested and the final result branches do not run. Earlier node outputs can still be visible in the editor. Treat the execution as incomplete.
Automatic retries are disabled. Resolve authentication or quota problems before restarting. A manual rerun can consume additional calls for already checked rows. If you later add retries for temporary failures, bound the attempts and delays; never retry invalid input or exhausted quota in a loop.
Before connecting production data
The starter disables saved manual, successful and failed execution data, plus saved progress. Verify these workflow settings after import. IBANs and API responses can still appear during execution, and your hosting, logging and backup policies also matter. Avoid pinning real customer data or sharing workflow exports containing it.
After a successful manual test, connect each result branch to your intended destination. Preserve source identifiers and prevent repeated runs from creating duplicate records. Add scheduling only after deciding the timezone, quota budget, error notification and restart behaviour.
What was checked
The included report records 24 passing offline checks using Node.js: JavaScript fixtures, normalization, duplicate handling, limits, strict result classification, contradictory-response rejection, and workflow configuration and connections. The node definitions were checked against official n8n documentation and source. No installed n8n runtime or API credential was available, so import, execution inside n8n, item-link resolution and authenticated API calls remain unverified. Perform the manual test above in your own instance before relying on the workflow.
For other starting points, see IBAN validation in Google Sheets or checking an IBAN CSV with Python.
