User verification webhooks are triggered throughout applicant verification. The flowchart below illustrates the standard verification flow and shows which webhooks are sent at each step. The order and presence of steps may vary depending on your verification level configuration. If your verification level uses a workflow, additional events apply and the behavior differs: - `applicantReviewed` is deferred until the workflow completes — it is not sent immediately after the moderator's decision. - Additional events can be sent: `applicantAwaitingUser`, `applicantAwaitingService`, `applicantWorkflowCompleted`, `applicantWorkflowFailed`.

`} {`

Webhook	Description
applicantCreated	New applicant record is created. This webhook is triggered when an applicant is created by any of the following methods: WebSDK or MobileSDK — SDK is initialized for the applicant for the first time. Verification links — applicant is created through a verification link: For a permalink, the applicant is created when the SDK is loaded. For a one-time link associated with an email address, phone number, or wallet, the applicant is created after ownership of the identifier is confirmed (for example, by entering the verification code or signing the wallet message). Direct API creation call — applicant is created through this API method. KYB beneficiary — when a beneficiary is added to a company applicant by any of the following: Client's operator. Direct API call. End user during the KYB step in the SDK.
applicantPending	Applicant's review status changes to `pending`. This webhook is triggered in any of the following cases: Standard verification Applicant completes a verification level in the SDK and submits it. Applicant is moved to `pending` via API or Dashboard. KYB verification: Beneficiary applicant reaches `pending`: After completing and submitting the KYB step in the SDK. After being moved to `pending` via API or Dashboard. Company applicant reaches `pending`: After all beneficiary applicants have been reviewed (KYB rollup). Via direct API call, bypassing the KYB rollup. The webhook is triggered only when the applicant's review status changes to `pending`. Repeated updates that keep the status as pending do not trigger the webhook.
applicantReviewed	Applicant receives a final verification result. This webhook is triggered by any of the following: Auto-check — auto-check completes with a verification result. Dashboard — client's operator submits a final decision. External-decision API — through Approve applicant or Reject applicant API methods, allowing the client to synchronize an approval or rejection decision from an external system (for example, a CRM) with Sumsub. Workflow — workflow reaches the final rejection node. KYB verification — company applicant is automatically finalized after beneficiary applicants have reached final statuses. If the company is rejected, this webhook is triggered for the company applicant. When the applicant is enrolled in a workflow, the per-level `applicantReviewed` webhook is normally not triggered. Instead, a single `applicantReviewed` webhook is sent after the workflow is completed.
applicantOnHold	Applicant's review status changes to `onHold`. This webhook is triggered by any of the following: Auto-check — auto-check determines that manual review is required and routes the applicant for operator review instead of approving or rejecting the application. Workflow node — a manual review node in the workflow moves the applicant or applicant action to `onHold` until an operator makes a decision. Self-review — a verification level configured for self-review routes an SDK or API submission directly to `onHold` instead of `pending`. Client's operator action — client's operator manually places the applicant on hold. AML ongoing recheck — a new watchlist match is detected for an already approved applicant and, depending on the ongoing watchlist configuration, the recheck is routed to `onHold` instead of `pending`. Video identification session — applicant starts a Video identification session and is moved to `onHold` until an operator joins the call. Unlike most review status changes, repeated transitions to `onHold` are not suppressed. The same applicant can trigger multiple `applicantOnHold` webhooks, for example when a new watchlist match places the applicant on hold again.
applicantActionPending	Applicant action's review status changes to `pending`. This webhook is triggered when the action enters `pending` by any of the following methods: WebSDK or MobileSDK — applicant completes the required action steps in the SDK and submits the action. Direct API or Dashboard call — action's `reviewStatus` is changed to `pending`. Recheck — action expiry recheck request, or an explicit re-initiation that resets the review and resubmits the action, changes the action's `reviewStatus` to `pending`. Face enrollment — `faceEnrollment` action receives a Liveness selfie and is moved from `init` to `pending`. The webhook is triggered only when the action's review status actually changes to `pending`. If the action is already in pending, the update is rejected, and the webhook is not triggered.
applicantActionReviewed	Applicant action receives a verification result. This webhook is triggered when the result is recorded by any of the following methods: Dashboard — client's operator approves the action or submits a rejection. Direct API call — client submits the action's review result or changes its review status to `completed`. Auto-check — server-side check (for example, a crypto transaction or payment method check) completes synchronously and records the action's review result without operator intervention. Workflow node — applicant action workflow completes, and the action receives a final approval or rejection. When the action is part of an active applicant workflow, the per-action webhook is not triggered immediately. Instead, it is sent after the workflow completes, ensuring that each terminal review produces exactly one `applicantActionReviewed` webhook.
applicantActionOnHold	Applicant action's review status changes to `onHold`. This webhook is triggered when the action enters `onHold` by any of the following methods: Auto-check — auto-check finishes with a non-GREEN result that requires manual review and routes the action for operator review. Workflow node — manual review node moves the action to `onHold` until an operator reviews it. Direct API or Dashboard call — review status change puts the action on hold. Self-review — SDK or API submission that would otherwise move the action to `pending` is redirected to `onHold` by the verification level's self-review setting. The webhook is triggered only when the action's review status actually changes to `onHold`. Repeating the same review status and reason is rejected, and the webhook is not triggered.
applicantActionLevelChanged	Applicant action is moved to a new verification level. This webhook is triggered when an applicant action level change node moves the action to the verification level configured on the node. This webhook is triggered only during a workflow execution. Direct API or Dashboard level changes do not trigger it. It is also triggered only when the action actually moves to a new verification level.
applicantPersonalInfoChanged	Applicant's personal information is updated. This webhook is triggered when any of the following information changes: Applicant information (`info`) — after changes made through this API method. Provided information (`fixedInfo`) — after changes made through this API method. Applicant profile — after changes made through this API method. The webhook is triggered when the update modifies `info`, `phone`, or `email`. Company information — after company information is updated for a company applicant. This webhook is triggered only if the applicant's review status is `completed`, `onHold`, `awaitingUser`, or `awaitingService`. Document deletion or document data merge — after an ID document containing extracted fields is deleted, or a beneficiary is removed from a company. This webhook is triggered only if the applicant's review status is `completed`, `onHold`, `awaitingUser`, or `awaitingService`. The webhook is triggered only when the update results in an actual change. It is not triggered if no changes are detected or, for document- and company structure-related updates, if the applicant has not yet reached one of the required review statuses.
applicantTagsChanged	Applicant's tags are updated. This webhook is triggered when the applicant's tags change by any of the following methods: Direct API call — through the Add and overwrite applicant tags, Add applicant tags, or Remove applicant tags API methods. Client's operator action — operator updates the applicant's tag in the Dashboard. Workflow node — tags action node adds or removes tags during workflow execution. Auto-check — client regulations auto-check adds a red flag tag when the questionnaire results in a red answer. External decision — external decision submitted via the API includes a tag list. The tags are applied after the review status changes. Case Management — a tag change case action updates the tags of the linked applicant during processing. The webhook is triggered only when the resulting tag set changes. It is not triggered if no tags are added or removed, if the updated tag set matches the existing one, or if a workflow computes the same tag set.
applicantActivated	Previously deactivated applicant is reactivated. This webhook is triggered when an applicant is reactivated by any of the following methods: Direct API patch — through this API method to change the applicant status back to `activated`. Client's operator action — operator reactivates the applicant in the Dashboard. The webhook is triggered only when the applicant transitions from `deactivated` to `activated`. It is not triggered if the applicant is already active. Restoring an applicant from the archive changes the applicant's presence status to `restored` and does not trigger this webhook.
applicantDeactivated	Applicant is deactivated. Deactivation is a recoverable soft-delete, and the applicant can later be reactivated. This webhook is triggered by any of the following methods: Client's operator action — operator deactivates the applicant in the Dashboard. Direct API call — applicant is deactivated using the corresponding API method. Applicant patch — applicant is deactivated through an applicant update (`PATCH /resources/applicants`). Deactivating an applicant requires the deactivateApplicants permission and is not allowed while the applicant's review is in progress. The webhook is triggered once when the applicant's status changes from `active` to `deactivated`. Repeated attempts to deactivate an already deactivated applicant do not trigger another webhook.
applicantDeleted	Applicant record is permanently deleted from the system. The applicant is removed from both the database and the search index, and their presence status changes to `deleted`. This webhook is triggered by any of the following methods: Direct API call — single applicant is deleted. Client's operator action — operator with the required permission deletes the applicant in the Dashboard. Bulk delete — bulk delete request can delete up to 100 applicants at a time. The webhook is triggered once for each successfully deleted applicant. Applicants that fail to delete are reported in the response and do not trigger the webhook. Retention-based scheduled deletion — applicant is deleted automatically after the configured retention period. This webhook is triggered only when the `fullDelete` strategy is used. The `personalData`, `personalDataPreserveSelfie`, and `documentPhotos` strategies trigger the applicantPersonalDataDeleted webhook instead. For KYB verifications, the webhook is triggered per applicant, not per company structure. Deleting a company applicant unlinks its beneficiaries but does not delete them. Each beneficiary must be deleted separately to trigger its own `applicantDeleted` webhook. The webhook is not triggered if the applicant has already been deleted from the database.
applicantReset	Applicant is fully reset. All checks, documents, and the Video identification state are cleared, and the applicant's review status changes to `init`. This webhook is triggered by any of the following methods: Client's operator action — operator resets the applicant in the Dashboard. Direct API call — applicant is reset using the corresponding API method. Step-reset escalation — partial step reset escalates to a full applicant reset if other verification steps are still red. Workflow node — applicant-level or action applicant transition workflow node resets document sets for a verification level. If other verification steps are still red, the reset escalates to a full applicant reset. SDK auto-reset — applicant is automatically reset when a new SDK session starts after an incomplete submission. Case Management — Case Management case executes the resetApplicant action for the linked applicant. A full applicant reset is blocked if the applicant's review is already in progress, except for Video identification applicants. If the reset is blocked, the webhook is not triggered.
applicantPrechecked	Note that `applicantPrechecked` is deprecated. It is no longer offered when creating a webhook. Webhooks that already have this type configured continue to work until removal. To be notified that an applicant has entered verification, use `applicantPending`. For the final verification outcome, use `applicantReviewed`. Applicant's review status changes to `prechecked`. This is an intermediate state used when the auto-check cannot make a final decision and must wait for one or more verification checks to complete. This webhook is triggered in any of the following cases: Auto-check — auto-check detects that one or more verification checks are still in progress, or starts additional checks and waits for their results instead of moving the applicant directly to the pending review queue. Pending checks — one or more verification checks are already in progress, so the auto-check is skipped and the applicant moves directly to `prechecked` until those checks are completed. After all blocking checks are completed, the applicant transitions to `pending` or `completed`, depending on the verification results. At that point, the applicantPending or applicantReviewed webhook is triggered.
applicantLevelChanged	Applicant moves from one verification level to another. This webhook is triggered by any of the following methods: Client's operator action — operator moves the applicant to another verification level in the Dashboard. Direct API call — applicant is moved using the corresponding API method. Workflow level node — workflow level node moves the applicant to the configured verification level. SDK applicant preparation — when an SDK session starts for an existing applicant configured to realign verification levels, the applicant is moved to the level specified by the access token. Reusable KYC reuse — donor applicant's verification data is reused for a recipient on a different verification level. Transaction Monitoring verification link — operator sends a transaction verification link, moving the linked applicant to the selected verification level before the email is sent. The webhook is triggered only when the applicant is actually moved to another verification level. It is not triggered if, for example, the target level is the same as the current level, or the change is blocked because the applicant's review is already in progress.
applicantRiskLevelChanged	Applicant's risk level changes. This webhook is triggered by any of the following methods: Automatic risk scoring — scoring model recalculates the applicant's risk level. Manual override — applicant's risk level is changed manually, via the Dashboard or the API. Workflow node — risk level action node sets the applicant's risk level. The webhook is triggered only when the applicant's risk level actually changes. Repeated overrides to the same risk level do not trigger the webhook.
applicantWorkflowCompleted	Applicant's workflow run is completed. This webhook is triggered when the workflow engine reaches the end of the workflow, and the workflow run transitions to the `completed` status. Workflow runs that end with the `canceled` status do not trigger this webhook. This webhook is also not triggered for applicant action workflow runs (verification of a single applicant action). Instead, those workflows trigger the applicantActionReviewed webhook.
applicantWorkflowFailed	Applicant's workflow run fails. This webhook is triggered in any of the following cases: Workflow node execution error — workflow node encounters an unrecoverable error during execution, or the workflow execution context closes unexpectedly while the workflow run is still in the `running` state. Verification level change — operator or API call moves the applicant to a verification level that the current workflow run can no longer reach, causing the workflow run to transition to the `failed` status. This webhook is not triggered for applicant action workflow runs. Instead, those workflows trigger the applicantActionReviewed webhook after the final review. The webhook is triggered only when the workflow run transitions from the `running` or `suspended` state to the `failed` status. Repeated updates that keep the workflow run in the failed state do not trigger the webhook again.
videoIdentStatusChanged	Review status of a Video identification session changes. The video call media is typically available shortly after this webhook is triggered, although processing time may vary. This webhook is triggered in any of the following cases: WebSDK or MobileSDK integration — new Video identification session is created when the applicant starts the Video identification step, and the session enters the `init` status. SDK readiness confirmation — applicant confirms readiness in the SDK, moving the session from `init` to `pending`. Client's operator action — operator manually changes the session review status, for example, resetting it to `init` or changing it to another review status. Call completion — operator completes the video call in the Dashboard, moving the session to `completed`. Applicant cancellation — applicant ends the call before it is picked up, resetting the session to `init`. The webhook is triggered only when the session's reviewStatus changes. For example, resetting a session that is already in the init status or confirming SDK readiness when the session is not in the `init` status does not trigger the webhook.
videoIdentCompositionCompleted	Video identification call recording is composed and attached to the applicant's profile. This webhook is triggered in any of the following cases: Hosted call — completed room recording is synchronized and stored locally. The webhook is triggered once for each newly synchronized recording. Self-hosted call — recorded room media is processed, stored, and attached to the corresponding background check. For self-hosted calls with audio transcription enabled, the webhook is triggered only after transcription (and optional subtitles) is completed. In this case, the payload includes the `videoIdentCompositionHasSubtitles` field. If audio transcription is disabled or the transcription task cannot be started, the webhook is triggered immediately after the recording is stored. A single video call can produce multiple recordings (one for each room within the same call), and each recording triggers its own webhook. The webhook is not triggered for recordings that have already been synchronized with the inspection. Re-running synchronization for the same room does not trigger the webhook again.
applicantAwaitingService	Applicant's review status changes to `awaitingService`. This indicates that the auto-check is waiting for the result of an internal or external service before the review can continue. This webhook is triggered when the auto-check reaches a node configured to wait for a service result. It applies to any applicant, including a KYB beneficiary applicant whose verification level includes a background check — the beneficiary remains in `awaitingService` until the background check provider returns a result. The webhook is triggered only when the applicant's review status changes to `awaitingService`. If the applicant is already in the `awaitingService`, the status is not written again and the webhook is not triggered.
applicantAwaitingUser	Applicant's review status changes to `awaitingUser`. This status indicates that the review is waiting for input from the applicant before it can continue. This webhook is triggered in any of the following cases: Transaction Monitoring recheck — transaction scoring action requires additional applicant input, or an operator sends a verification link from the Transaction Monitoring page, moving the transaction to the `awaitingUser` status until the applicant resubmits the required information. Client's operator action or direct API call — applicant's review status is manually changed to `awaitingUser`. This webhook is separate from the Documents requested and Resubmission requested applicant statuses, which trigger their own webhook events. The webhook is triggered only when the applicant's review status changes to `awaitingUser`. If the applicant already has the `awaitingUser` status with the same `reasonCode`, the webhook is not triggered again.
applicantStepsReset	One or more applicant verification steps are reset without performing a full applicant reset. This webhook is triggered in any of the following cases: Client's operator action — operator resets a specific verification step from the applicant profile. Direct API call — verification step is reset through this API method. Verification level change — corresponding API method is called with an `applicantResetConf` configuration, resetting the specified document steps, KYB sub-steps, and Video identification on the new level. Workflow node — applicant transition or applicant level workflow node resets the configured verification steps. This webhook is not triggered when the step reset results in a full applicant reset. For example, if a rejected verification step remains after the targeted reset and full reset on step reset is enabled, the applicantReset webhook is triggered instead. The webhook is also not triggered if no verification step, KYB sub-step, or Video identification step is actually reset.
applicantPersonalDataDeleted	Applicant's personal data or stored document images are permanently erased. This webhook is triggered in the following case: Retention-based scheduled deletion — asynchronous cleanup job runs according to the configured data retention policy after the retention period expires. The cleanup can be scheduled based on when the applicant is created, copied, or reaches a terminal review status. The webhook is triggered when the cleanup process permanently removes the applicant's data, not when the applicant's review status changes. Each successful cleanup operation triggers the webhook once. This webhook is not triggered when an applicant is fully deleted. In that case, the applicantDeleted webhook is triggered instead.
companyStructureChanged	List of beneficiaries for a company applicant changes. This webhook is triggered in any of the following cases: Client's operator action — operator adds or removes a beneficiary from the company profile. Direct API call — beneficiary is added to the company applicant using the corresponding API method, or removed using this API method. WebSDK or MobileSDK integration — applicant adds or removes a beneficiary during the KYB flow. Beneficiary applicant cleanup — beneficiary applicant is permanently removed and automatically unlinked from each associated company applicant. The webhook is triggered once for each affected company. This webhook applies only to company applicants. Each beneficiary change triggers the webhook once. Consecutive add, remove, or unlink operations each produce a separate webhook.
applicantVerificationLinkOpened	Applicant opens a verification link or initializes the SDK for the first time. This webhook is triggered in any of the following cases: WebSDK or MobileSDK integration — SDK is initialized and resolves the verification configuration for the applicant. Verification link — applicant opens a WebSDK verification link. If no applicant exists when the link is opened, the webhook is triggered after the applicant is created during the next SDK initialization. Unilink (one-time link) — applicant verifies ownership of the email address, phone number, or wallet associated with the link, and an applicant is created. The webhook is not triggered for requests made by web crawlers. Repeated openings of the same verification configuration are deduplicated within a one-minute window. Reopening the same configuration during that period does not trigger the webhook again.
verificationLinkSdkEvent	Applicant enters or completes a verification step in the WebSDK. This webhook is triggered in any of the following cases: Step entered — applicant opens a verification step. The webhook is sent with `stepState` set to `initiated`. Step completed — applicant completes a verification step. The webhook is sent with `stepState` set to `completed`. Final screens — `verificationInProgress`, `verificationCompleted`, and `restrictedAccess` — are reported with `initiated` only, because the applicant does not complete them. This webhook is triggered only when the applicant opens the WebSDK as a standalone page through a link on a Sumsub domain, including: Verification link — applicant goes through verification using a unilink or a permalink. KYB beneficiary link — beneficiary goes through verification using a link sent during the KYB flow. Continue on phone — applicant continues verification on a mobile device. The events come from the session on the phone, even when the original session was embedded. The webhook is not triggered for embedded WebSDK integrations, which receive the corresponding events in the browser, or for MobileSDK integrations. The `reusableKycAgreement` and `reusableKyc2fa` steps are not reported. Repeated events for the same verification attempt, step, and step state are deduplicated within a two-minute window. Reloading the page, reopening the link, or returning to a step during that period does not trigger the webhook again. When the verification is reset, a new attempt begins, and events for the new attempt are sent right away. Deduplication is best-effort, so make your webhook handler idempotent.
applicantShareTokenConsumed	Applicant share token has been consumed and applicant data has been successfully reused. This webhook supports both applicant share tokens and Sumsub ID share tokens.
applicantShareTokenFailed	Applicant share token reuse failed. This webhook supports both applicant share tokens and Sumsub ID share tokens.

`} ### Note Personal applicant information is not available in the webhook payload. To get this information, use [this API method](/reference/get-applicant-data). ### Tip If you are not receiving webhooks, try to check your endpoints using [SSL Labs](https://www.ssllabs.com/ssltest/) or Docker. # applicantCreated ```json { "applicantId": "5c9e177b0a975a6eeccf5960", "inspectionId": "5c9e177b0a975a6eeccf5961", "applicantType": "individual", "correlationId": "req-63f92830-4d68-4eee-98d5-875d53a12258", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantCreated", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-02-21 13:23:19.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type:
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `reuseScope` | String | An optional field that indicates that the applicant status was applied through a data reuse process, where the data source is either a Sumsub ID profile or a previous applicant verification.

This field is included only in the webhook triggered by the initial status change. It is not included in subsequent webhooks generated after the copy process is complete, such as those related to checks or later status updates.

Possible values indicate the way the applicant's initial status was obtained:
\- `reusableKycSdk` — WebSDK Reusable KYC via email/phone.
\- `reusableKycSdkViaSumsubNetwork` — WebSDK Reusable KYC via Sumsub Network.
\- `reusableKycSdkShareToken` — WebSDK Reusable KYC via share token.
\- `reusableKycApiShareToken` — API Reusable KYC via share token.
\- `reusableKycApiSnsIdShareToken` — API Reusable KYC via Sumsub ID share token.
\- `importApiShareToken` — Copy Applicant via share token.
\- `snsIdConnect` — Sumsub ID Connect.
\- `snsId` — Sumsub ID. | | `type` | String | Webhook type. In this context, it is `applicantCreated`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantPending ```json { "applicantId": "5c7791f80a975a1df426b9e9", "inspectionId": "5c7791f80a975a1df426b9ea", "applicantType": "individual", "correlationId": "req-4af54c06-6a50-4cb9-a7dc-b94b2f5b07eb", "levelName": "liveness-level", "externalUserId": "12672", "type": "applicantPending", "sandboxMode": false, "reviewStatus": "pending", "createdAtMs": "2020-02-21 13:23:19.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `reuseScope` | String | **Optional** field that indicates that the applicant status was applied through a data reuse process, where the data source is either a Sumsub ID profile or a previous applicant verification.

This field is included only in the webhook triggered by the initial status change. It is not included in subsequent webhooks generated after the copy process is complete, such as those related to checks or later status updates.

Possible values indicate the way the applicant's initial status was obtained:
\- `reusableKycSdk` — WebSDK Reusable KYC via email/phone.
\- `reusableKycSdkViaSumsubNetwork` — WebSDK Reusable KYC via Sumsub Network.
\- `reusableKycSdkShareToken` — WebSDK Reusable KYC via share token.
\- `reusableKycApiShareToken` — API Reusable KYC via share token.
\- `reusableKycApiSnsIdShareToken` — API Reusable KYC via Sumsub ID share token.
\- `importApiShareToken` — Copy Applicant via share token.
\- `snsIdConnect` — Sumsub ID Connect.
\- `snsId` — Sumsub ID. | | `type` | String | Webhook type. In this context, it is `applicantPending`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `reviewMode` | String | **Optional** field that may be present if Ongoing Monitoring is enabled for your project.

Available values:
\- `ongoingAml` — applicant review is currently in progress due to [Ongoing AML monitoring](https://docs.sumsub.com/docs/ongoing-aml-monitoring), which has placed the review in the `pending` status.
\- `ongoingDocExpired` — applicant review is currently in progress due to [Ongoing document monitoring](https://docs.sumsub.com/docs/ongoing-document-monitoring), which has placed the review in the `pending` status. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantReviewed ```json Temporary rejection { "applicantId": "69e5d579e37291e569b75ce5", "inspectionId": "69e5d579e37291e569b75ce5", "applicantType": "individual", "correlationId": "ffdf14510f0bdde909a2e5f9988f92ec", "levelName": "1doc", "sandboxMode": false, "externalUserId": "dash-6ccde837-640a-49b9-a2f9-f096f561744c", "type": "applicantReviewed", "reviewResult": { "reviewAnswer": "RED", "rejectLabels": [ "BAD_PROOF_OF_IDENTITY" ], "reviewRejectType": "RETRY", "buttonIds": [ "badDocument_suspiciousDocument", "badDocument" ] }, "reviewStatus": "completed", "createdAtMs": "2026-04-30 08:04:23.379", "clientId": "coolClientId" } ``` ```json Final rejection { "applicantId": "69e5d579e37291e569b75ce5", "inspectionId": "69e5d579e37291e569b75ce5", "applicantType": "individual", "correlationId": "ffdf14510f0bdde909a2e5f9988f92ec", "levelName": "1doc", "sandboxMode": false, "externalUserId": "dash-6ccde837-640a-49b9-a2f9-f096f561744c", "type": "applicantReviewed", "reviewResult": { "moderationComment": "We couldn't verify your profile. If you have any questions, please contact the support email of the company you are verifying for support@coolclient.com", "clientComment": "User identity is compromised:\n- PEP\n- Sanction lists", "reviewAnswer": "RED", "rejectLabels": [ "COMPROMISED_PERSONS", "PEP", "SANCTIONS" ], "reviewRejectType": "FINAL", "buttonIds": [ "compromisedPersons_sanctionList", "compromisedPersons_pep", "compromisedPersons" ] }, "reviewStatus": "completed", "createdAtMs": "2026-04-30 08:04:23.379", "clientId": "coolClientId" } ``` ```json Success { "applicantId": "5cb56e8e0a975a35f333cb83", "inspectionId": "5cb56e8e0a975a35f333cb84", "applicantType": "individual", "correlationId": "req-a260b669-4f14-4bb5-a4c5-ac0218acb9a4", "externalUserId": "externalUserId", "levelName": "id-and-liveness", "type": "applicantReviewed", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2020-02-21 13:23:19.321", "clientId": "coolClientId" } ``` | Field | Type | Description | | -------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `reuseScope` | String | **Optional** field that indicates that the applicant status was applied through a data reuse process, where the data source is either a Sumsub ID profile or a previous applicant verification.

This field is included only in the webhook triggered by the initial status change. It is not included in subsequent webhooks generated after the copy process is complete, such as those related to checks or later status updates.

Possible values indicate the way the applicant's initial status was obtained:
\- `reusableKycSdk` — WebSDK Reusable KYC via email/phone.
\- `reusableKycSdkViaSumsubNetwork` — WebSDK Reusable KYC via Sumsub Network.
\- `reusableKycSdkShareToken` — WebSDK Reusable KYC via share token.
\- `reusableKycApiShareToken` — API Reusable KYC via share token.
\- `reusableKycApiSnsIdShareToken` — API Reusable KYC via Sumsub ID share token.
\- `importApiShareToken` — Copy Applicant via share token.
\- `snsIdConnect` — Sumsub ID Connect.
\- `snsId` — Sumsub ID. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `type` | String | Webhook type. In this context, it is `applicantReviewed`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](https://docs.sumsub.com/reference/get-applicant-review-status#reviewresult-attributes) | Contains the applicant verification results data. For more information, refer to [this article](doc:receive-and-interpret-results-via-api). To find out about `buttonIds` and `rejectLabels`, refer to [Resubmission requested](ref:resubmission-requested) and [Rejected](ref:rejected). | | `reviewResult.clientComment` | String | Human-readable comment that should not be shown to your applicants.

This field will contain applicant top-level comments and—if `reviewRejectType` is `FINAL`—it may also contain some private information which should not be shared with anyone except administrative personnel on the client side. | | `reviewResult.moderationComment` | String | Human-readable comment that explains the reasons for rejection in detail, and that can be shown to the applicant. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `reviewMode` | String | **Optional** field that may be present if Ongoing Monitoring is enabled for your project.

Available values:
\- `ongoingAml` — applicant review is currently in progress due to [Ongoing AML monitoring](https://docs.sumsub.com/docs/ongoing-aml-monitoring), which has placed the review in the `pending` status.
\- `ongoingDocExpired` — applicant review is currently in progress due to [Ongoing document monitoring](https://docs.sumsub.com/docs/ongoing-document-monitoring), which has placed the review in the `pending` status. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantOnHold ```json { "applicantId": "5c7791f80a975a1df426b9e9", "inspectionId": "5c7791f80a975a1df426b9ea", "applicantType": "individual", "correlationId": "req-4af54c06-6a50-4cb9-a7dc-b94b2f5b07eb", "levelName": "liveness-level", "externalUserId": "12672", "type": "applicantOnHold", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "onHold", "createdAtMs": "2020-02-21 13:23:19.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantOnHold`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `reviewMode` | String | **Optional** field that may be present if Ongoing Monitoring is enabled for your project.

Available values:
\- `ongoingAml` — applicant review is currently in progress due to [Ongoing AML monitoring](https://docs.sumsub.com/docs/ongoing-aml-monitoring), which has placed the review in the `pending` status.
\- `ongoingDocExpired` — applicant review is currently in progress due to [Ongoing document monitoring](https://docs.sumsub.com/docs/ongoing-document-monitoring), which has placed the review in the `pending` status. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantActionPending ```json { "applicantId": "5dc158b109494c3cbf431e28", "applicantActionId": "5dc2d80ce3cc9b1c1e389c4c", "externalApplicantActionId": "id122424234-random-r7otyykndi", "inspectionId": "5dc158b109494c3cbf431e29", "applicantType": "individual", "correlationId": "req-8fbf5a81-339f-43b6-a9a7-290080e9039c", "levelName": "basic-action-level", "externalUserId": "pid122424235", "type": "applicantActionPending", "sandboxMode": false, "reviewStatus": "completed", "createdAtMs": "2020-02-21 13:23:16.001", "clientId": "coolClientId" } ``` | Field | Type | Description | | --------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `applicantActionId` | String | Unique identifier of the applicant action in the Sumsub system. | | `externalApplicantActionId` | String | Identifier of the applicant action on your side. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantActionPending`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantActionReviewed ```json { "applicantId": "5dc158b109494c3cbf431e28", "applicantActionId": "5dc2d80ce3cc9b1c1e389c4c", "externalApplicantActionId": "id122424234-random-r7otyykndi", "inspectionId": "5dc158b109494c3cbf431e29", "applicantType": "individual", "correlationId": "req-c9041677-e8dc-446b-ab8f-50b438a40aa8", "levelName": "basic-action-level", "externalUserId": "id122424234", "type": "applicantActionReviewed", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2020-02-21 13:23:19.001", "clientId": "coolClientId" } ``` | Field | Type | Description | | --------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `applicantActionId` | String | Unique identifier of the applicant action in the Sumsub system. | | `externalApplicantActionId` | String | Identifier of the applicant action on your side. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantActionReviewed`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-action-information#reviewresult-attributes) | Contains information about the verification results. For more information, refer to [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantActionOnHold ```json { "applicantId": "5ea867a9772e27d66728c64b", "applicantActionId": "5ea867c2772e27d66728c64f", "externalApplicantActionId": "random-4gguvx1oha-action-v1_5", "inspectionId": "5ea867a9772e27d66728c64c", "applicantType": "individual", "correlationId": "req-2c3cce19-c723-4fd0-a2f2-527789f95bcc", "levelName": "basic-action-level", "externalUserId": "random-4gguvx1oha", "type": "applicantActionOnHold", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-04-28 18:16:09.001", "clientId": "coolClientId" } ``` | Field | Type | Description | | --------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `applicantActionId` | String | Unique identifier of the applicant action in the Sumsub system. | | `externalApplicantActionId` | String | Identifier of the applicant action on your side. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantActionOnHold`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantActionLevelChanged ```json { "applicantId": "696929a8b27d2a0277812936", "applicantActionId": "69a5440cdbd0ab0c1aac97f3", "externalApplicantActionId": "preview-action-random-LFXu9-v1_5", "inspectionId": "696929a8b27d2a0277812936", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eads", "levelName": "actionLevelActualName", "sandboxMode": false, "externalUserId": "level-19a01a4c-5552-4552-ae24-8a4ed9e3b43e", "type": "applicantActionLevelChanged", "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2026-03-30 16:37:52.266", "clientId": "coolClientId" } ``` | Field | Type | Description | | --------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `applicantActionId` | String | Unique identifier of the applicant action in the Sumsub system. | | `externalApplicantActionId` | String | Identifier of the applicant action on your side. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantActionLevelChanged`. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, refer to [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantPersonalInfoChanged ```json { "applicantId": "5ede51230a975a19a19ba5c1", "inspectionId": "5ede51230a975a19a19ba5c2", "applicantType": "individual", "correlationId": "req-60103dee-79f1-43f4-bdcc-eb2554556afa", "levelName": "id+liveness", "externalUserId": "12672", "type": "applicantPersonalInfoChanged", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2020-06-08 19:39:29.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantPersonalInfoChanged`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, refer to [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantTagsChanged ```json { "applicantId": "5ede51230a975a19a19ba5c1", "inspectionId": "5ede51230a975a19a19ba5c2", "applicantType": "individual", "correlationId": "req-60103dee-79f1-43f4-bdcc-eb2654556afa", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantTagsChanged", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2023-06-08 19:39:29.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantTagsChanged`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantActivated ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eada", "levelName": "phone-level", "externalUserId": "12672", "type": "applicantActivated", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:18:33.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantActivated`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantDeactivated ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eada", "levelName": "phone-level", "externalUserId": "12672", "type": "applicantDeactivated", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:18:33.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantDeactivated`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantDeleted ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eada", "levelName": "phone-level", "externalUserId": "12672", "type": "applicantDeleted", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:18:33.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantDeleted`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantReset ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-57fed49a-07b8-4413-bdaa-a1be903769e9", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantReset", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "init", "createdAtMs": "2021-03-01 11:34:51.104", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantReset`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantPrechecked ### Deprecated Note that `applicantPrechecked` is deprecated. It is no longer offered when creating a webhook. Webhooks that already have this type configured continue to work until removal. To be notified that an applicant has entered verification, use applicantPending. For the final verification outcome, use applicantReviewed. ```json { "applicantId": "5d1f2914c2d75a1c14130bd2", "inspectionId": "5d1f2914c2d75a1c14130bd3", "applicantType" : "individual", "correlationId": "req-e9d77142-59e6-4713-9b07-9b342cc51dda", "levelName": "kyc", "externalUserId": "12672", "type": "applicantPrechecked", "sandboxMode": false, "reviewStatus": "prechecked", "createdAtMs": "2020-02-21 13:23:19.002", "clientId": "SumsubClient" } ``` | Field | Type | Description | | ---------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantPrechecked`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `reviewMode` | String | **Optional** field that may be present if Ongoing Monitoring is enabled for your project.

Available values:
\- `ongoingAml` — applicant review is currently in progress due to [Ongoing AML monitoring](https://docs.sumsub.com/docs/ongoing-aml-monitoring), which has placed the review in the `pending` status.
\- `ongoingDocExpired` — applicant review is currently in progress due to [Ongoing document monitoring](https://docs.sumsub.com/docs/ongoing-document-monitoring), which has placed the review in the `pending` status. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | This webhook carries no `reviewResult` object — the verification result is only available once the applicant reaches a final status. # applicantLevelChanged ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eadd", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantLevelChanged", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:19:33.002", "clientId": "coolClientId" } ```

Field	Type	Description
`applicantId`	String	Unique identifier of the applicant in the Sumsub system.
`inspectionId`	String	A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.\ ⚠️ As of now, \`inspectionId\` is deprecated but still returned in the webhook.
`applicantType`	String	Defines the applicant entity type. `individual` — for applicants registered and checked as individuals. `company` — for applicants registered and checked as legal entities.
`correlationId`	String	A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation.
`levelName`	String	Name of the [verification level](doc:verification-levels) the applicant has to go through.
`externalUserId`	String	Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub.
`type`	String	Webhook type. In this context, it is `applicantLevelChanged`.
`sandboxMode`	Boolean	Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode).
`testMode`	Boolean	\[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`. Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send.
`reviewStatus`	String	Current [applicant review status](ref:get-applicant-review-status#review-statuses).
`createdAtMs`	Date	Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example,`2021-05-14 16:00:25.032`) in UTC.
`clientId`	String	Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created.

# applicantRiskLevelChanged ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eadd", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantRiskLevelChanged", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:19:33.002", "clientId": "coolClientId" } ```

Field	Type	Description
`applicantId`	String	Unique identifier of the applicant in the Sumsub system.
`inspectionId`	String	A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.\ ⚠️ As of now, \`inspectionId\` is deprecated but still returned in the webhook.
`applicantType`	String	Defines the applicant entity type. `individual` — for applicants registered and checked as individuals. `company` — for applicants registered and checked as legal entities.
`correlationId`	String	A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation.
`levelName`	String	Name of the [verification level](doc:verification-levels) the applicant has to go through.
`externalUserId`	String	Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub.
`type`	String	Webhook type. In this context, it is `applicantRiskLevelChanged`.
`sandboxMode`	Boolean	Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode).
`testMode`	Boolean	\[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`. Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send.
`reviewStatus`	String	Current [applicant review status](ref:get-applicant-review-status#review-statuses).
`createdAtMs`	Date	Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example,`2021-05-14 16:00:25.032`) in UTC.
`clientId`	String	Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created.

# applicantWorkflowCompleted ```json { "applicantId": "64106d6b7d5a2d5159e6b01a", "inspectionId": "64106d6b7d5a2d5159e6b01b", "applicantType": "individual", "correlationId": "req-57fed49a-07b8-4413-bdaa-a1be903769e9", "levelName": "id-and-liveness", "sandboxMode": false, "externalUserId": "12672", "type": "applicantWorkflowCompleted", "reviewResult": { "reviewAnswer": "RED", "rejectLabels": [ "AGE_REQUIREMENT_MISMATCH" ], "reviewRejectType": "FINAL", "buttonIds": [] }, "reviewStatus": "completed", "workflowRevision": 8, "createdAtMs": "2023-03-14 12:50:27.238", "clientId": "coolClientId" } ``` | Field | Type | Description | | ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantReset`. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `workflowRevision` | Integer | Published revision number of the applicant workflow that ran for this applicant. Optional — omitted when the revision is unknown. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantWorkflowFailed ```json { "applicantId": "64106d6b7d5a2d5159e6b01a", "inspectionId": "64106d6b7d5a2d5159e6b01b", "applicantType": "individual", "correlationId": "req-57fed49a-07b8-4413-bdaa-a1be903769e9", "levelName": "id-and-liveness", "sandboxMode": false, "externalUserId": "12672", "type": "applicantWorkflowFailed", "reviewResult": { "reviewAnswer": "RED", "rejectLabels": [ "AGE_REQUIREMENT_MISMATCH" ], "reviewRejectType": "FINAL", "buttonIds": [] }, "reviewStatus": "completed", "workflowRevision": 8, "createdAtMs": "2023-03-14 12:50:27.238", "clientId": "coolClientId" } ``` | Field | Type | Description | | ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantReset`. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `workflowRevision` | Integer | Published revision number of the applicant workflow that ran for this applicant. Optional — omitted when the revision is unknown. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # videoIdentStatusChanged ```json Initialized { "applicantId": "596928690a975a137c5b207e", "inspectionId": "596928690a975a137c5b207a", "applicantType": "individual", "correlationId": "req-a7812631-2c40-4f13-8407-fd42a516f0b0", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "videoIdentStatusChanged", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "videoIdentReviewStatus": "pending", "createdAtMs": "2020-10-16 12:34:25.003", "clientId": "coolClientId" } ``` | Field | Type | Description | | ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantReset`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | Object | Contains information about the verification results. For more information, see this article. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `videoIdentReviewStatus` | String | Status of the [VideoIdent](doc:video-identification) call. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # videoIdentCompositionCompleted ```json { "applicantId": "596928690a975a137c5b207e", "inspectionId": "596928690a975a137c5b207a", "applicantType": "individual", "correlationId": "req-a7812631-2c40-4f13-8407-fd42a516f0b0", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "videoIdentCompositionCompleted", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "videoIdentCompositionMediaId": "596928690a975a137", "createdAtMs": "2020-10-16 12:34:25.003", "clientId": "coolClientId" } ``` | Field | Type | Description | | ------------------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantReset`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `videoIdentCompositionMediaId` | String | Unique identifier of the Video Call record. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantAwaitingService ```json { "applicantId": "5c7791f80a975a1df426b9e9", "inspectionId": "5c7791f80a975a1df426b9ea", "applicantType": "individual", "correlationId": "req-4af54c06-6a50-4cb9-a7dc-b94b2f5b07eb", "levelName": "basic-kyc-level", "externalUserId": "12672", "type": "applicantAwaitingService", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "awaitingService", "createdAtMs": "2025-02-21 13:23:19.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantAwaitingService`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantAwaitingUser ```json { "applicantId": "5c7791f80a975a1df426b9e9", "inspectionId": "5c7791f80a975a1df426b9ea", "applicantType": "individual", "correlationId": "req-4af54c06-6a50-4cb9-a7dc-b94b2f5b07eb", "levelName": "basic-kyc-level", "externalUserId": "12672", "type": "applicantAwaitingUser", "sandboxMode": false, "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "awaitingUser", "createdAtMs": "2025-02-21 13:23:19.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantAwaitingUser`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewResult` | [Object](ref:get-applicant-review-status#reviewresult-attributes) | Contains information about the verification results. For more information, see [this article](doc:receive-and-interpret-results-via-api). | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantStepsReset ```json { "applicantId": "5f194e74040c3f316bda271c", "inspectionId": "5f194e74040c3f316bda271d", "applicantType": "individual", "correlationId": "req-d34c974c-5935-41b8-a0a9-cedd2407eadd", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "applicantStepsReset", "sandboxMode": false, "reviewStatus": "init", "createdAtMs": "2020-07-23 11:19:33.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantAwaitingUser`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantPersonalDataDeleted ```json { "applicantId": "5ede51230a975a19a19ba5c1", "inspectionId": "5ede51230a975a19a19ba5c2", "applicantType": "individual", "correlationId": "req-60103dee-79f1-43f4-bdcc-eb2554556afa", "levelName": "id+liveness", "externalUserId": "12672", "type": "applicantPersonalDataDeleted", "sandboxMode": false, "reviewStatus": "completed", "createdAtMs": "2020-06-08 19:39:29.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantAwaitingUser`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # companyStructureChanged ```json { "applicantId": "5ede51230a975a19a19ba5c1", "inspectionId": "5ede51230a975a19a19ba5c2", "applicantType": "individual", "correlationId": "req-60103dee-79f1-43f4-becc-eb2554556afa", "levelName": "basic-kyb-level", "externalUserId": "12672", "type": "companyStructureChanged", "sandboxMode": false, "reviewStatus": "pending", "createdAtMs": "2025-01-09 19:39:29.002", "clientId": "coolClientId" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantAwaitingUser`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `reviewStatus` | String | Current [applicant review status](ref:get-applicant-review-status#review-statuses). | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | # applicantVerificationLinkOpened ```json { "applicantId": "5c9e177b0a975a6eeccf5960", "applicantType": "individual", "correlationId": "da9564f4437c9fcd059f99e0b94fa04d", "levelName": "basic-kyc-level", "externalUserId": "12672", "type": "applicantVerificationLinkOpened", "sandboxMode": false, "createdAtMs": "2026-04-24 13:23:19.002" } ``` | Field | Type | Description | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `applicantType` | String | Defines the applicant entity type.

individual — for applicants registered and checked as individuals.
company — for applicants registered and checked as legal entities.

| | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `externalUserId` | String | Unique applicant identifier as registered on your side.
When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `type` | String | Webhook type. In this context, it is `applicantVerificationLinkOpened`. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode). | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example,`2021-05-14 16:00:25.032`) in UTC. | # verificationLinkSdkEvent ```json { "applicantId": "5c9e177b0a975a6eeccf5960", "inspectionId": "5c9e177b0a975a6eeccf5961", "applicantType": "individual", "correlationId": "req-63f92830-4d68-4eee-98d5-875d53a12258", "levelName": "id-and-liveness", "externalUserId": "12672", "type": "verificationLinkSdkEvent", "sandboxMode": false, "stepType": "idDocSet", "stepState": "initiated", "idDocSetType": "IDENTITY", "reviewStatus": "init", "createdAtMs": "2020-02-21 13:23:19.002", "clientId": "coolClientId" } ```

Field	Type	Description
`applicantId`	String	Unique identifier of the applicant in the Sumsub system.
`inspectionId`	String	Unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created. Note: As of now, `inspectionId` is deprecated but still returned in the webhook.
`applicantType`	String	Defines the applicant entity type. `individual` — for applicants registered and checked as individuals. `company` — for applicants registered and checked as legal entities.
`correlationId`	String	A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation.
`levelName`	String	Name of the [verification level](doc:verification-levels) the applicant has to go through.
`externalUserId`	String	Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub.
`type`	String	Webhook type. In this context, it is `verificationLinkSdkEvent`.
`sandboxMode`	Boolean	Set to `true` if the webhook was sent from [Sandbox](doc:sandbox-mode).
`stepType`	String	Verification step the applicant has entered or completed: `welcome`, `welcomeWithAgreement`, `agreement`, `idDocSet`, `videoIdent`, `realTimeIdentificationRecording`, `resubmissionOverview`, `verificationInProgress`, `verificationCompleted`, or `restrictedAccess`. Document collection steps are reported as `idDocSet`, with the particular step given in `idDocSetType`.
`stepState`	String	Stage of the step: - `initiated` — the applicant has entered the step. - `completed` — the applicant has completed the step.
`idDocSetType`	String	Verification step the applicant has entered or completed, for example `IDENTITY` or `SELFIE`. Returned when `stepType` is `idDocSet`. For the full list of values, see [Verification steps (idDocSetTypes)](ref:iddocsettypes).
`applicantActionId`	String	Unique identifier of the applicant action in the Sumsub system. Returned only when the step belongs to an applicant action.
`externalApplicantActionId`	String	Unique applicant action identifier as registered on your side. Returned only when the step belongs to an applicant action.
`reviewStatus`	String	Current applicant review status.
`createdAtMs`	Date	Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example,`2021-05-14 16:00:25.032`) in UTC.
`clientId`	String	Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created.

# applicantShareTokenConsumed ```json { "applicantId": "69e73745a8d18f533e008b4f", "inspectionId": "69e73745a8d18f533e008b4f", "applicantType": "individual", "correlationId": "984fc12a5727f636e70658f023c28615", "levelName": "R312Test", "sandboxMode": false, "externalUserId": "level-1a03d5c4-b700-4e3f-ace1-ac0f64816cd1", "reuseScope": "reusableKycApiShareToken", "type": "applicantShareTokenConsumed", "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAtMs": "2026-04-28 11:04:03.763", "clientId": "cross", "shareTokenForClientId": "cross" } ``` | Field | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `reuseScope` | String | **I**ndicates that the applicant status was applied through a data reuse process, where the data source is either a Sumsub ID profile or a previous applicant verification.

This field is included only in the webhook triggered by the initial status change. It is not included in subsequent webhooks generated after the copy process is complete, such as those related to checks or later status updates.

Possible values indicate the way the applicant's initial status was obtained:
\- `reusableKycSdk` — WebSDK Reusable KYC via email/phone.
\- `reusableKycSdkViaSumsubNetwork` — WebSDK Reusable KYC via Sumsub Network.
\- `reusableKycSdkShareToken` — WebSDK Reusable KYC via share token.
\- `reusableKycApiShareToken` — API Reusable KYC via share token.
\- `reusableKycApiSnsIdShareToken` — API Reusable KYC via Sumsub ID share token.
\- `importApiShareToken` — Copy Applicant via share token.
\- `snsIdConnect` — Sumsub ID Connect.
\- `snsId` — Sumsub ID. | | `type` | String | Webhook type. In this context, it is `applicantShareTokenConsumed`. | | `reviewResult` | Object | Contains the applicant verification results data. For more information, refer to this article. To find out about `buttonIds` and `rejectLabels`, refer to Resubmission requested and Rejected. | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | | `shareTokenForClientId` | String | Client ID for which the applicant share token was generated. | | `shareTokenSha256` | String | SHA-256 hash of the consumed share token. Present in share token webhook payloads.

For a Sumsub ID share token with no loadable donor applicant, use it to correlate the callback with the token you issued. | ### Important When a Sumsub ID share token is consumed but the donor applicant record can no longer be loaded, this webhook is still sent with a reduced payload. It omits `applicantId` and all applicant-derived fields, and carries `reuseScope`, `shareTokenForClientId`, and `shareTokenSha256`. Match the token on `shareTokenSha256` rather than expecting an `applicantId`. ```json Donor-less payload example { "correlationId": "b4f56ddde46da21a4563d6f3c0162c6b", "sandboxMode": false, "reuseScope": "reusableKycApiSnsIdShareToken", "type": "applicantShareTokenConsumed", "createdAt": "2026-09-18 07:21:36+0000", "createdAtMs": "2026-09-18 07:21:36.969", "clientId": "oso", "shareTokenForClientId": "cross", "shareTokenSha256": "e004892b73135c7a3a4aa220a2c8703822c5bab86a49f2e2afb17b7dc050b6d7" } ``` # applicantShareTokenFailed ```json { "applicantId": "69e63528ce75608127ca084e", "inspectionId": "69e63528ce75608127ca084e", "applicantType": "individual", "correlationId": "5db743f5d65ea41a38c7fb8f8ce7fd5f", "levelName": "PoaLiveness", "sandboxMode": false, "externalUserId": "level-06072dc2-8579-4e60-8d6b-9cd16e38d18e", "reuseScope": "reusableKycApiShareToken", "type": "applicantShareTokenFailed", "reviewResult": { "reviewAnswer": "GREEN" }, "reviewStatus": "completed", "createdAt": "2026-04-28 11:14:08+0000", "createdAtMs": "2026-04-28 11:14:08.614", "clientId": "cross", "shareTokenForClientId": "oso", "shareTokenErrorName": "reusable-kyc-not-req-doc-overlap" } ``` | Field | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `applicantId` | String | Unique identifier of the applicant in the Sumsub system. | | `inspectionId` | String | A unique combination of digits and characters previously used to identify all actions related to the applicant's ID documents. Added automatically when the applicant is created.
⚠️ As of now, `inspectionId` is deprecated but still returned in the webhook. | | `applicantType` | String | Defines the applicant entity type.
\- `individual` — for applicants registered and checked as individuals.
\- `company` — for applicants registered and checked as legal entities. | | `correlationId` | String | A shared identifier assigned to the originating request and propagated across all related events. Multiple events may share the same `correlationId` when triggered by the same operation. | | `levelName` | String | Name of the [verification level](doc:verification-levels) the applicant has to go through. | | `sandboxMode` | Boolean | Set to `true` if the webhook was sent from Sandbox. | | `testMode` | Boolean | \[Optional] Present and set to `true` only if the webhook was sent manually in the Webhook manager. This field is omitted for real (production) webhooks — check for its presence or `true`, not for `false`.

Independent of `sandboxMode`, which indicates the Sandbox environment rather than a manual test send. | | `externalUserId` | String | Unique applicant identifier as registered on your side. When [creating an applicant](ref:create-applicants), you can generate and add the `externalUserId` manually, or it will be automatically generated and added to the applicant profile by Sumsub. | | `reuseScope` | String | **I**ndicates that the applicant status was applied through a data reuse process, where the data source is either a Sumsub ID profile or a previous applicant verification.

This field is included only in the webhook triggered by the initial status change. It is not included in subsequent webhooks generated after the copy process is complete, such as those related to checks or later status updates.

Possible values indicate the way the applicant's initial status was obtained:
\- `reusableKycSdk` — WebSDK Reusable KYC via email/phone.
\- `reusableKycSdkViaSumsubNetwork` — WebSDK Reusable KYC via Sumsub Network.
\- `reusableKycSdkShareToken` — WebSDK Reusable KYC via share token.
\- `reusableKycApiShareToken` — API Reusable KYC via share token.
\- `reusableKycApiSnsIdShareToken` — API Reusable KYC via Sumsub ID share token.
\- `importApiShareToken` — Copy Applicant via share token.
\- `snsIdConnect` — Sumsub ID Connect.
\- `snsId` — Sumsub ID. | | `type` | String | Webhook type. In this context, it is `applicantShareTokenFailed`. | | `reviewResult` | Object | Contains the applicant verification results data. For more information, refer to this article. To find out about `buttonIds` and `rejectLabels`, refer to Resubmission requested and Rejected. | | `reviewStatus` | String | [Current status](ref:action-statuses) of the applicant action. | | `createdAtMs` | Date | Date and time when the webhook was created, considering milliseconds (format `yyyy-MM-dd HH:mm:ss.fff`, for example, `2021-05-14 16:00:25.032`) in UTC. | | `clientId` | String | Unique identifier of you as our client in the Sumsub system. This identifier is assigned to you when you are registered in and get access to the Sumsub system. It usually resembles your name or your company name. `clientId` is automatically added to the applicant profile when it is created. | | `shareTokenForClientId` | String | Client ID for which the applicant share token was generated. | | `shareTokenErrorName` | String | Error name explaining why the applicant share token could not be consumed.

For the full list of error codes with descriptions, refer to [this article](https://docs.sumsub.com/reference/reuse-applicant-for-reusable-kyc#error-codes-with-descriptions). |