> ## Documentation Index > Fetch the complete documentation index at: https://docs.iron.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Get customer requirements > Retrieve a requirements view of a customer: four buckets — `complete`, `pending`, `missing`, `issues` — plus a coarse `requirements_due` summary of categories that still need attention. Each requirement carries a stable typed `code` (switch on this) and, when available, a verbatim `description` from the upstream KYC provider's moderation comment. **NOTE**: The `description` field is subject to change without notice. Computed on demand from the customer's identifications and customer-level state; no separate ingestion step is needed. ## OpenAPI ````yaml /spec.yaml get /customers/{id}/requirements openapi: 3.1.0 info: description: The Stablecoin Payment Network title: Iron API - Sandbox version: 1.0-16884 servers: - url: https://api.sandbox.iron.xyz/api security: [] tags: - description: >- Wallet and bank account registration Every wallet address that interacts with Iron must be registered (linked) to a customer **before** it can be used in any flow — onramp, offramp, or swap. This is a regulatory requirement under the **Travel Rule**, which obliges Virtual Asset Service Providers to exchange originator and beneficiary information for crypto transfers. Iron supports two wallet types: - **Self-hosted wallets** — the customer controls the private key. Registration requires a signed proof-of-ownership message. - **Hosted wallets** — the wallet is custodied by another VASP (e.g. Coinbase, Kraken). Registration requires the VASP's DID so Iron can exchange travel-rule data with the custodian. Similarly, fiat bank accounts must be registered before they can receive offramp payouts. name: Addresses - description: Operations on Autoramp name: Autoramp - description: Operations on Chronicle collateral name: ChronicleCollateral - description: Operations on Currencies name: Currencies - description: Operations on Customers name: Customer - description: Operations on Exchange Rate name: ExchangeRate - description: Operations on Fee Profiles name: FeeProfiles - description: Operations for Sandbox Testing name: Sandbox - description: Operations on SSE name: Sse - description: Operations on Terms and Conditions name: TermsAndConditions - description: Operations on Webhooks name: Webhooks paths: /customers/{id}/requirements: get: tags: - Customer summary: Get customer requirements description: >- Retrieve a requirements view of a customer: four buckets — `complete`, `pending`, `missing`, `issues` — plus a coarse `requirements_due` summary of categories that still need attention. Each requirement carries a stable typed `code` (switch on this) and, when available, a verbatim `description` from the upstream KYC provider's moderation comment. **NOTE**: The `description` field is subject to change without notice. Computed on demand from the customer's identifications and customer-level state; no separate ingestion step is needed. operationId: getCustomerRequirements parameters: - deprecated: false description: >- Optional sub-partner UUID, if provided, the customer will be filtered for the sub-partner explode: true in: header name: X-SUB-PARTNER-ID required: false schema: type: string - deprecated: false description: the ID of the Customer to GET requirements for explode: true in: path name: id required: true schema: format: uuid type: string - $ref: '#/components/parameters/XApiVersion' responses: '200': content: application/json; charset=utf-8: schema: $ref: '#/components/schemas/CustomerRequirements' description: GET Customer Requirements Succeeded '401': content: application/json; charset=utf-8: schema: type: string description: GET Customer Requirements Failed (Unauthorized) '404': content: application/json; charset=utf-8: schema: type: string description: GET Customer Requirements Failed (Resource Not Found) '500': content: application/json; charset=utf-8: schema: $ref: '#/components/schemas/ApiError' description: GET Customer Requirements Failed (Internal Error) security: - ApiKeyAuth: [] components: parameters: XApiVersion: description: >- Selects the API version for this request, as an ISO date (`YYYY-MM-DD`). Omit to use the default version (`2025-03-13`). Supported versions: 2025-03-13, 2026-07-01. in: header name: X-API-Version required: false schema: type: string schemas: CustomerRequirements: description: |- Bridge-style requirements view of a customer. All four buckets are always present (may be empty). `requirements_due` is a quick coarse summary — partners can use it to decide whether any action is needed before drilling into the detail buckets. properties: complete: description: Requirements the customer has satisfied. items: $ref: '#/components/schemas/RequirementItem' type: array issues: description: Terminal blockers the customer cannot self-remediate. items: $ref: '#/components/schemas/RequirementItem' type: array missing: description: Requirements the customer can still satisfy (resubmittable). items: $ref: '#/components/schemas/RequirementItem' type: array pending: description: Requirements the customer has submitted, awaiting review. items: $ref: '#/components/schemas/RequirementItem' type: array requirements_due: description: |- Sorted, deduplicated set of categories that have at least one non-complete item. Empty for fully-onboarded customers. items: $ref: '#/components/schemas/RequirementCategory' type: array required: - requirements_due - complete - pending - missing - issues title: CustomerRequirements type: object ApiError: description: |- Standard error response returned to API clients for server errors. Includes a trace_id that clients can reference when reporting issues. properties: message: description: Human-readable error message type: string trace_id: description: Trace ID that can be used to look up request details in logs type: string required: - message - trace_id title: ApiError type: object RequirementItem: description: |- A single requirement entry returned in one of the four buckets on `ApiCustomerRequirements`. properties: code: $ref: '#/components/schemas/RequirementCode' description: description: |- Human-readable reason from Sumsub — the moderation comment and the applicant-facing client comment combined (moderator note first, deduped), or a synthesized note for the identification-level codes. May be `null`. *IMPORTANT*: This field is subject to change without notice — switch on `code` (and `reject_labels`), not on this string. type: string identification_id: description: The identification that produced this item, when applicable. format: uuid type: string reject_labels: description: |- Coded Sumsub rejection reasons for this step (e.g. `SCREENSHOTS`, `UNSATISFACTORY_PHOTOS`) — the pills shown in the Sumsub dashboard. Empty when the step carries no labels. items: type: string type: array retryable: description: |- `true` if the customer can resubmit to clear this item (Sumsub `reject_type == Retry`). `false` for terminal/Final rejections. `null` for `complete`/`pending` items, where retry semantics don't apply. type: boolean required: - code - reject_labels title: RequirementItem type: object RequirementCategory: description: |- Coarse summary of which areas of the customer's Sumsub KYC/KYB process still need attention. Used as a quick filter — full detail lives in the four `complete`/`pending`/`missing`/`issues` buckets. enum: - kyc - kyb type: string RequirementCode: description: |- Stable, switchable identifier for a single requirement. Partners should branch on this rather than parsing `description`, which holds the verbatim text from Sumsub (and is subject to change without notice). enum: - kyc_selfie - kyc_identity - kyc_proof_of_residence - kyc_questionnaire - kyb_company_data - kyb_company_beneficiaries - kyb_company_documents - kyb_questionnaire - identification_kyc - identification_kyb - kyc_data_missing - kyc_data_invalid - kyb_data_missing - kyb_data_invalid type: string securitySchemes: ApiKeyAuth: description: API Key in: header name: X-API-Key type: apiKey ````