Thank you for choosing our API! This documentation will guide you through making your first request to validate an IBAN.
Getting Started
This API is a JSON-based REST API. You'll interact with it via HTTP. The Base URL is:
https://www.iban-validator.de/api/v1
Validating a single IBAN
To validate a singular IBAN, you're going to use the /valiate/:IBAN endpoint.
Here's an example using curl:
curl -X GET \
-H "Accept: application/json" \
"https://www.iban-validator.de/api/v1/validate/DE89370400440532013000?token=YOUR_API_TOKEN"
Your response will look like this:
{
"valid": true,
"messages": [
"Bank code valid: 37040044"
],
"iban": "DE89370400440532013000",
"bankData": {
"bankCode": "37040044",
"name": "Commerzbank",
"zip": 50447,
"city": "Köln",
"bic": "COBADEFFXXX"
},
"checks": {
"validCountry": true,
"validLength": true,
"validChecksum": true,
"validBlz": true
}
}
To explain:
- The
validboolean describes whether the validation has been successful. If this is false, your request will look a little different, but more on that later. - The
messagesarray contains a human-readable status message of the validation result. - The
bankDataobject contains information about the bank that issued the IBAN. - The
checksobject shows which checks have passed / failed so you can display status messages based on what happened.
Here's what a failed request would look like:
{
"valid": false,
"messages": [
"Invalid length for German IBAN."
],
"checks": {
"validCountry": true,
"validLength": false,
"validChecksum": false,
"validBlz": false
}
}
The valid boolean is now false, the messages array contains the reason for why the request failed, and you can use the checks to construct your own message to show to a user.
Validating multiple IBANs at once
Alternatively, you can issue bulk requests to the /api/v1/validate endpoint with a POST request.
You must have your Content-Type header set to either application/json (in which you need to pass an array of IBANs in your request body) or multipart/form-data; boundary=... (in which case you need to pass the IBANs via a multipart form CSV file which has one column that is prefixed with the column name "IBAN").
Here's an example using curl with JSON data:
curl -X POST \
-H "Content-Type: application/json" \
-d '["DE89370400440532013000", "DE8937040044053201300"]' \
"https://www.iban-validator.de/api/v1/validate?token=YOUR_API_TOKEN"
This is what the JSON request body should look like:
[
"DE89370400440532013000",
"DE8937040044053201300"
]
If you want to use a CSV file, it should be structured like this:
| IBAN |
|---|
| DE89370400440532013000 |
| DE8937040044053201300 |
| ... |
If it contains other columns, they will be ignored, meaning this will still work:
| Customer | IBAN | Registration Date |
|---|---|---|
| John Doe | DE89370400440532013000 | 07.05.2024 |
| John F. Kennedy | DE8937040044053201300 | 01.01.1970 |
| ... | ... | ... |
You will receive a JSON response with all IBAN validation results in the order that you gave the IBANs in:
[
{
"valid": true,
"messages": [
"Bank code valid: 37040044"
],
"iban": "DE89370400440532013000",
"bankData": {
"bankCode": "37040044",
"name": "Commerzbank",
"zip": 50447,
"city": "Köln",
"bic": "COBADEFFXXX"
},
"checks": {
"validCountry": true,
"validLength": true,
"validChecksum": true,
"validBlz": true
}
},
{
"valid": false,
"messages": [
"Invalid length for German IBAN."
],
"checks": {
"validCountry": true,
"validLength": false,
"validChecksum": false,
"validBlz": false
}
}
]
Response Status Codes
| Status Code | Type | Description |
|---|---|---|
| 200 | OK | The request succeeded. The result and meaning of "success" depends on the HTTP method. |
| 301 | Moved Permanently | The URL of the requested resource has been changed permanently. The new URL is given in the response. |
| 400 | Bad Request | The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). |
| 403 | Forbidden | The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401 Unauthorized, the client's identity is known to the server. |
| 500 | Internal Server Error | The server has encountered a situation it does not know how to handle. This error is generic, indicating that the server cannot find a more appropriate 5XX status code to respond with. |