An IBAN copied from a document often arrives with spaces. Before an app can do much with it, it needs a consistent representation and a way to check whether the number follows the rules for its country.
That is what /iban does. Pass the number as you have it, and the response gives you the electronic form for storage and the spaced form for display. These are the relevant fields for the standard German example:
GET /iban/DE89%203704%200044%200532%200130%2000
{
"iban": "DE89370400440532013000",
"valid": true,
"country": "DE",
"formatted": "DE89 3704 0044 0532 0130 00"
}
valid means the number has the expected length and structure and passes the checksum. It doesn't mean an account with that number is open, or that it belongs to the person who entered it. Those questions require information a parsing check doesn't have.
The response includes the bank identifier where the country's format defines it. Add ?deep=true for checksum digits, branch, and account identifiers, included on every plan. A bank name or BIC can come from an official directory when we have a matching record. That identifies the institution. It doesn't turn the result into an account check.
If the number fails validation, the API returns valid: false in a normal response. A form can keep the person's input, explain that the number needs another look, and let them correct it. A successful result gives you a normalized IBAN to pass to the next step.