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.

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 tags 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

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 — a 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.

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.

applicantShareTokenConsumed

Applicant share token has been consumed and applicant data has been successfully reused.

This webhook supports applicant share tokens only and is not sent for Sumsub ID share tokens.

applicantShareTokenFailed

Applicant share token reuse failed.

This webhook supports applicant share tokens only and is not sent for Sumsub ID share tokens.