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.
Example 400 response
Example 400 response
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.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.
Example 200 response excerpt
Example 200 response excerpt
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 inreject_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.