An account number can start with a zero. Converting "0001234567" to a number gives you 1234567, and converting it back to a string won't recover what the person entered. The value has changed before validation begins.
Keep routing and account numbers as text from the input field through storage and the API request. In Bank, US ACH details use an explicit format and country. This illustrative request uses a made-up account number. It is not payment information:
POST /bank
Parse-Version: 2.0.0
Content-Type: application/json
{
"format": "us_ach",
"country": "US",
"routing": "021000021",
"account": "0001234567"
}
Both identifiers must be JSON strings. A numeric account is a malformed request, even if the digits would otherwise fit. If an earlier system already removed a leading zero, ask for the original details. Padding to a guessed length would create another account number.
The two fields have different normalization rules. Bank removes accepted spaces and separators from the routing number before checking its nine digits and checksum. The account comes back exactly as submitted, including case, leading zeros, spaces and hyphens.
That account field has a supported collection format: ASCII letters, digits, spaces and hyphens, with at least one letter or digit. Its length is one to seventeen positions after excluding spaces. Hyphens still count. Each input also has a limit of 128 raw characters. Those are this endpoint's acceptance rules. A receiving bank or payment provider may have additional requirements.
For a form that needs those rules before someone enters their details, GET /bank/requirements?country=US&format=us_ach returns field metadata and limitations. It needs your API key but no account number.
Put the correction beside the field
A completed check returns checks and an ordered issues array. Each issue has a field, code and message, so an incorrect routing checksum can appear beside the routing input without clearing the account input.
HTTP 200 with valid: false means the submitted details failed an applicable check. HTTP 400 means the request needs correcting, such as sending a number where a string is required. An unavailable check should leave the form ready to try again, rather than label the account invalid.
account_checksum is always not_supported. Don't turn that into a green checkmark. Even when valid is true, the result establishes only the supported account format and routing checksum. Account existence, ownership and ACH eligibility still need their own verification.
The Bank reference describes the full response. Keep the person's original account text alongside the result so a later step gets the same identifier they supplied.