Get customer requirements
API 2026-10-01 returns catalog descriptions and separate review feedback, validation occurrences, and rejected document steps. Earlier versions retain the legacy shape. The default when X-API-Version is omitted remains unchanged. Customers without stored requirements show the identification-level requirement. Only applicant-facing feedback is included on this route.
Authorizations
API Key
Headers
Optional sub-partner UUID, if provided, the customer will be filtered for the sub-partner
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, 2026-08-01, 2026-10-01, 2026-10-15.
Path Parameters
the ID of the Customer to GET requirements for
Response
GET Customer Requirements Succeeded
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.
Requirements the customer has satisfied.
Submitted requirements that were rejected or could not be processed.
Inspect retryable to distinguish correctable from terminal issues.
Requirements the customer has never submitted.
Requirements the customer has submitted, awaiting review.
Sorted, deduplicated set of categories that have at least one non-complete item. Empty for fully-onboarded customers.
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.
kyc, kyb Curated, partner-safe summary of the async preflight pipeline (document/selfie analysis + workflow predictor) — backfilled onto an identification once that pipeline finishes. Deliberately narrower than the full internal result: no internal level names, trace/correlation ids, or per-check evaluation names — those stay internal/backoffice-only.