Skip to main content
This page covers two code sets: identification error codes, returned as 400 errors by POST /api/customers/{id}/identifications/v2, and customer requirement codes, returned inside a 200 response by GET /api/customers/{id}/requirements.

Identification error codes

POST /api/customers/{id}/identifications/v2 validates Business, Person, and Token submissions synchronously. From X-API-Version: 2026-08-01, a failed submission returns 400 with an array of error objects. Earlier and unversioned callers get a plain string. See API Versions.
Always iterate the array. Most checks return one entry, but the four document checks (company_details_required, legal_presence_required, ownership_structure_required, control_structure_required) report every missing group at once.
string
required
Stable identifier from the table below. Match on this.
string
required
Details for this occurrence, such as the exact field or beneficiary. It can change without notice, so don’t match on it.
string
required
Link to the code’s row on this page: https://docs.iron.xyz/errors#<code>.
integer
Zero-based index into company_data.beneficiaries. Set only on Business errors tied to one beneficiary.
Link identifications only open a hosted flow, so they skip this validation. The one exception: with_edd: true on a Business customer returns invalid_request.

Customer requirement codes

GET /api/customers/{id}/requirements with X-API-Version: 2026-10-01 or later reports problems with a customer’s submission as data, not as an HTTP error. The request returns 200, and each problem is an entry in the issues array. These codes are separate from the identification error codes above: they describe why a requirement isn’t satisfied yet, not why a request failed. Each issue lists review rejections in reject_reasons[].error_code, and per document step in steps[].reject_reasons[].error_code. Values come from Verification rejection codes.
Switch on error_code. The description text can change without notice. Use retryable on the issue to decide whether the customer can fix and resubmit: true permits a correction, false is terminal, and null means retryability is unknown. See Checking Outstanding Requirements for the full response and customer-facing feedback guidance.

Verification rejection codes

Returned in reject_reasons[].error_code when the verification review rejects a requirement or one of its document steps. A review reason without a mapped code returns verification_unknown_rejection, so handle that value as a fallback. Screening, fraud, and policy rejections aren’t returned on this endpoint, so an issue can come back with an empty reject_reasons array.