--- updatedAt: 2026-10-01T12:26:10.000Z agentTools: projectIndex: https://docs.sumsub.com/llms.txt --- # Get Reusable KYC reports # Overview Use this read-only endpoint to retrieve structured Reusable KYC reports for a specific applicant. The method does not recalculate or save anything; it simply fetches pre-existing `REUSABLE_KYC_REPORT` checks from the applicant's inspection and presents them in a clean, detailed, inline format. This lets you see exactly which check results and values (such as country, age, or document type) were inherited during the reuse process. ## Required permissions To use this method, your [app token](https://docs.sumsub.com/sumsub/docs/app-tokens) must have the **View check results** [permission](https://docs.sumsub.com/sumsub/docs/user-roles#permissions). # Request example ```curl curl -X GET \ 'https://api.sumsub.com/api/reusableIdentity/69ce35c7b776d140bb500000/reports?levelName=basic-kyc-level' \ -H 'Content-Type: application/json' \ -H 'X-App-Token: ' \ -H 'X-App-Access-Sig: ' \ -H 'X-App-Access-Ts: ' ``` # Response explained The response is a JSON object representing a list of structured Reusable KYC reports for the applicant. ## `reports[]` element fields | Field | Type | Description | | -------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------- | | `fromClientId` | String | Identifier of the client account that originally verified the applicant and shared this report. | | `levelName` | String | Name of the verification level used to generate the report. | | `createdAt` | String | Date and time the report was created, in `yyyy-MM-dd HH:mm:ss` format. | | `reuseParams` | [Object](#reuseparams-attributes) | Parameters defining how verification data was reused. | | `dataGroups` | [Array of objects](#datagroups-element-fields) | List of data groups included in the report. | ## `reuseParams` attributes
Field Type Description
`preservedVerificationStatus` Boolean Effective `preservedVerificationStatus` value the reuse ran with. - `true` — the donor verification status was preserved as is. - `false` — steps with a non-green report result were reset.
`requireFreshSelfie` Boolean Effective `requireFreshSelfie` value the reuse ran with; only meaningful when `preservedVerificationStatus` is `false`. - `true` — the selfie step was reset regardless of the report. - `false` — the selfie step was reset only when the liveness/faceMatch report groups were not green.
## `dataGroups[]` element fields | Field | Type | Description | | -------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | String | Type of the data group. One of `applicantData`, `poi`, `liveness`, `faceMatch`, `duplicateCheck`, `crossCheck`, `email`, `phone`, `questionnaire`, `questionnaire2`, `questionnaire3`, `questionnaire4`.

A `questionnaire` (or `questionnaire2` - `questionnaire4`) group represents a questionnaire step required by the recipient level. When the reused (donor) applicant never completed that questionnaire, the group is returned with `answer: IGNORED` — see the note below. | | `answer` | String | Overall result of the data group. One of `GREEN` (check passed, no issues), `RED` (check failed, violations found), or `IGNORED`. `IGNORED` marks a step that is required at the recipient's verification level but had no check copied from the donor — the step is listed so you can detect it is missing, and carries no `checks`. | | `checks` | [Array of objects](#checks-element-fields) | Individual checks performed within the data group, if any. | ### Note A `questionnaire`/`questionnaire2`–`questionnaire4` group with `answer: IGNORED` (Check was skipped) means the recipient level requires a questionnaire step that the reused applicant did not complete on the donor level. The step is reported so you can see it was missing at reuse time, and the reused applicant is not force-approved while it is outstanding — the recipient must complete the questionnaire. Steps that were already passed on the donor are still carried over as `GREEN`. ## `checks[]` element fields | Field | Type | Description | | ------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `type` | String | Type of the check, for example, `allowedCountry`, `allowedDocType`, `unexpired`, `acceptableAge`, `acceptablePageCnt`, `noDuplicates`, `matchedRules`, `email`, `phone`. | | `answer` | String | Result of the check. One of `GREEN`, or `RED`. | | `country` | String | Country code the document was issued in. Present only for the `allowedCountry` check. | | `docType` | String | Type of the submitted document. Present only for the `allowedDocType` check. | | `validUntil` | String | Document's expiration date. Present only for the `unexpired` check. | | `age` | Number | Applicant's age at the time of the check. Present only for the `acceptableAge` check. | | `email` | String | Present on an `email` check. The confirmed email address. | | `phone` | String | Present on a `phone` check. The confirmed phone number. | # Response examples If the request is successfully sent and processed, you will get a response like the one below. ```json { "reports": [ { "fromClientId": "client_name", "levelName": "basic-kyc-level", "createdAt": "2026-07-03 12:26:11", "reuseParams": { "preservedVerificationStatus": false, "requireFreshSelfie": true }, "dataGroups": [ { "type": "applicantData", "answer": "IGNORED" }, { "type": "questionnaire", "answer": "IGNORED" }, { "type": "poi", "answer": "GREEN", "checks": [ { "type": "allowedCountry", "answer": "GREEN", "country": "ESP" }, { "type": "allowedDocType", "answer": "GREEN", "docType": "RESIDENCE_PERMIT" }, { "type": "unexpired", "answer": "GREEN", "validUntil": "2027-02-11" }, { "type": "acceptableAge", "answer": "GREEN", "age": 30 }, { "type": "acceptablePageCnt", "answer": "GREEN" } ] }, { "type": "liveness", "answer": "GREEN" }, { "type": "faceMatch", "answer": "GREEN" }, { "type": "duplicateCheck", "answer": "GREEN", "checks": [ { "type": "noDuplicates", "answer": "GREEN" } ] }, { "type": "crossCheck", "answer": "GREEN", "checks": [ { "type": "matchedRules", "answer": "GREEN" } ] }, { "type": "email", "answer": "GREEN", "checks": [ { "type": "email", "answer": "GREEN", "email": "john.doe@example.com" } ] }, { "type": "phone", "answer": "GREEN", "checks": [ { "type": "phone", "answer": "GREEN", "phone": "+15551234567" } ] } ] } ] } ``` If the request fails, you will receive an HTTP response containing an error code along with a message explaining the error. For example: ```json { "code": 404, "description": "Applicant not found" } ``` # OpenAPI definition ```json { "openapi": "3.1.0", "info": { "title": "sumsub-api", "version": "1.0" }, "servers": [ { "url": "https://api.sumsub.com" } ], "components": { "securitySchemes": { "sec0": { "type": "apiKey", "name": "X-App-Token", "in": "header", "x-default": "" } } }, "security": [ { "sec0": [] } ], "paths": { "/resources/api/reusableIdentity/{applicantId}/reports": { "get": { "responses": { "200": { "description": "" } }, "parameters": [ { "in": "path", "name": "applicantId", "schema": { "type": "string" }, "required": true, "description": "Unique applicant identifier in the Sumsub system.

This identifier is a random combination of 24 digits and lowercase Latin characters. It is automatically generated when the applicant is created on the Sumsub side, and can be found in the [Dashboard](https://cockpit.sumsub.com/checkus/#/applicants/individual?limit=10&page=0).

If the `applicantId` is unknown to you, use the [Get applicant data (externalUserId)](https://docs.sumsub.com/sumsub/reference/get-applicant-data-via-externaluserid) method to fetch it." }, { "in": "query", "name": "levelName", "schema": { "type": "string" }, "description": "Name of the [verification level](https://docs.sumsub.com/sumsub/docs/verification-levels) to filter the reports. If omitted or blank, no filtering is applied.

⚠️ Mind the following:
  • The level has to be created in the same [environment](https://docs.sumsub.com/sumsub/docs/sandbox-mode). For example, in the Sandbox mode, you may not be able to use a level configured to be only available in the Production environment.
  • A level name is case-sensitive. Kyc-level and kyc-level are considered as completely different level names. The system does not allow creating an applicant with the level name that does not exist.
  • If a level name contains reserved characters (for example, @, +, white spaces as %20), it should be URL-encoded; otherwise you may get a signature mismatch.
" } ], "summary": "Get Reusable KYC reports", "security": [ { "sec0": [] } ], "operationId": "get_resources-api-reusableidentity-applicantid-reports", "x-internal": false } } }, "x-readme": { "headers": [], "explorer-enabled": true, "proxy-enabled": true }, "x-readme-fauxas": true } ```