Updates watchlist screening state for a specific verification session
- Only available for customers using the Veriff PEP and Sanctions services
Supported operations
- This endpoint supports three mutually exclusive operations. Each request must contain exactly one
of the following top-level fields. Sending more than one in the same request results in a
400error.
Operation 1: review a hit (hit field)
Update a specific screening hit. Provide the hit
id(from the GET /v1/sessions//watchlist-screening endpoint response). SendmatchStatus,riskLevel, andisWhitelistedas optional fields depending on what you want to update.You can combine these optional fields in the same request when the combination satisfies the validation rules below.
matchStatusvalues (optional):false_positive: the hit is not a real match (e.g., common name coincidence)potential_match: the hit requires further investigation (default value)true_match: the hit is confirmed as a real matchinconclusive: unable to determine if the hit is a real match
riskLevelvalues (optional; can be sent together withmatchStatus: true_match, or on its own to update the risk level of a hit that is already reviewed astrue_match; sending it for any other hit returns a400error):low: the confirmed match represents low riskhigh: the confirmed match represents high risk
isWhitelistedvalues (optional):true: whitelist the hit and stop receiving ongoing monitoring updates for itfalse: remove the hit from the whitelist
Whitelisting follows the review decision automatically:
- Setting
matchStatustofalse_positivealso whitelists the hit. - Changing a hit from
false_positiveto any othermatchStatusremoves it from the whitelist, unless you sendisWhitelisted: truein the same request. - Changing between other
matchStatusvalues (for examplepotential_matchtotrue_match) keeps the current whitelisting.
- Setting
Operation 2: acknowledge monitoring changes (hasUnacknowledgedChanges field)
- Acknowledge that all changes from ongoing monitoring have been reviewed. Only the value
falseis accepted.
Operation 3: disable monitoring (monitorStatus field)
- Disable ongoing monitoring for the session. Only the value
disabledis accepted. - To check if ongoing monitoring is currently enabled, use the
GET /v1/sessions//watchlist-screening
endpoint and examine the
monitorStatusparameter.
Validation rules
- Exactly one top-level field (
hit,hasUnacknowledgedChanges, ormonitorStatus) per request - Sending
riskLevelis optional and is accepted withmatchStatus: true_match, or on its own for a hit that is already reviewed astrue_match; if the resulting hit review state is nottrue_match, the endpoint returns a400error - Un-whitelisting (
isWhitelisted: false) a hit reviewed asfalse_positive, or sendingisWhitelisted: falsetogether withmatchStatus: false_positive, returns a400error hasUnacknowledgedChangesonly acceptsfalsemonitorStatusonly acceptsdisabled- If monitoring is already disabled, the endpoint returns a
400error
Implementation notes
- This endpoint requires session-level HMAC signature authentication
- Always ensure that you use the correct API URL to send requests. See the API URL section for more info.
- The order of parameters in the real API response can differ from the order you see in this documentation. This is expected and part of the Backwards compatible changes requirements.
Your integration's API key (occasionally referred to as the "Token", "API public key" or "Publishable key"). Required for all API requests.
You can find your API key in the Veriff Customer Portal > Settings > API keys.
Request body signed with the shared secret key. Required to authenticate the request sender.
Request content type.
Verification session ID.
Watchlist screening update request. Exactly one of the three top-level fields must be provided.
Review a hit as true match with high risk
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"matchStatus": "true_match",
"riskLevel": "high"
}
}Review a hit as false positive
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"matchStatus": "false_positive"
}
}Review a hit as potential match
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"matchStatus": "potential_match"
}
}Whitelist a hit
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"isWhitelisted": true
}
}Remove a hit from the whitelist
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"isWhitelisted": false
}
}Update the risk level of a hit already reviewed as true match
{
"hit": {
"id": "4KJL9THDX9ZNV4W",
"riskLevel": "high"
}
}Acknowledge monitoring changes
{
"hasUnacknowledgedChanges": false
}Disable ongoing monitoring
{
"monitorStatus": "disabled"
}Request body for updating watchlist screening. Exactly one of the three top-level fields must be provided per request.
The fields hit, hasUnacknowledgedChanges, and monitorStatus are mutually exclusive.
Object containing the hit review update. At least one of matchStatus, riskLevel, or isWhitelisted is required.
The unique identifier of the hit to review.
The review decision for this hit. Optional when you are updating only riskLevel for a hit that is already reviewed as true_match, or only isWhitelisted.
Setting it to false_positive also whitelists the hit; changing a false_positive hit to another value removes it from the whitelist, unless isWhitelisted: true is sent in the same request.
Risk level assessment for this hit. Optional; can be sent together with matchStatus: true_match, or on its own to update the risk level of a hit that is already reviewed as true_match; sending it for any other hit returns a 400 error.
Set to true to whitelist the hit and stop receiving ongoing monitoring updates for it, false to remove it from the whitelist; removing a hit reviewed as false_positive from the whitelist is not allowed.
Takes precedence over the automatic whitelisting that follows matchStatus.
Must be set to false to acknowledge that all monitoring changes have been reviewed.
Only false is accepted as a value.
Must be set to disabled to turn off ongoing monitoring.
Watchlist screening updated successfully
Watchlist screening updated successfully
Response after a successful PATCH operation (hit review or acknowledge changes). Returns the current screening state.
{
"status": "success",
"data": {
"attemptId": "aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7",
"sessionId": "f04bdb47-d3be-4b28-b028-a652feb060b5",
"vendorData": "customer_ref_12345",
"endUserId": "c1de400b-1877-4284-8494-071d37916197",
"checkType": "initial_result",
"matchStatus": "possible_match",
"reviewStatus": "reviewed",
"hasUnacknowledgedChanges": false,
"monitorStatus": "enabled",
"searchTerm": {
"name": "GADDAFI",
"year": "1942",
"lists": [
"SANCTIONS",
"PEP_CLASS_1"
],
"countries": [
"US",
"GB"
],
"exactMatch": false,
"matchThreshold": 80,
"excludeDeceased": true
},
"totalHits": 1,
"createdAt": "2021-07-05T13:23:59.851Z",
"hits": [
{
"id": "4KJL9THDX9ZNV4W",
"matchStatus": "true_match",
"riskLevel": "high",
"isWhitelisted": false,
"matchedName": "Mouammar Mohammed Abu Minyar Kadhafi",
"countries": [
"Libya",
"US"
],
"dateOfBirth": "1942",
"dateOfDeath": "2011",
"matchTypes": [
"matching_name"
],
"aka": [
"Moammar Qaddafi"
],
"associates": [
"Saif al-Islam Gaddafi"
],
"listingsRelatedToMatch": {
"warnings": [],
"sanctions": [
{
"sourceName": "UN Security Council Sanctions",
"sourceUrl": "https://www.un.org/securitycouncil/sanctions",
"date": "2011-02-26"
}
],
"fitnessProbity": [],
"pep": [
{
"sourceName": "ComplyAdvantage PEP data",
"sourceUrl": null,
"date": null
}
],
"adverseMedia": []
}
}
]
}
}Monitoring disabled successfully
{
"status": "success",
"data": {
"attemptId": "aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7",
"sessionId": "f04bdb47-d3be-4b28-b028-a652feb060b5",
"vendorData": "1234567890",
"monitorStatus": "disabled"
}
}API request status.
Data containing PEP & Sanctions result details.
UUID v4 which identifies session attempt.
UUID v4 which identifies session.
The unique identifier that you created for your end-user. It can be max 1,000 characters long and contain only non-semantic data that can not be resolved or used outside your systems or environments. Veriff returns it unmodified in webhooks and API response payloads, or as null if not provided.
End-user-specific UUID created by the customer to identify the end-user. Returned unmodified in webhooks and public API calls, or as null if not provided.
Indicates if the response is for the initial check or a subsequent check. Relevant only if ongoing-monitoring has been enabled for your integration.
Deprecated. Use reviewStatus instead.
Indicates if there was a match in the database.
Overall review status of the watchlist screening hits.
no_match: no hits were found in PEP/Sanctions databasesreviewed: all hits have been reviewed by the customerpotential_match: hits exist that have not yet been fully reviewed
Indicates whether there are unacknowledged changes from ongoing monitoring that require attention.
Use the PATCH endpoint with hasUnacknowledgedChanges: false to acknowledge changes.
Indicates if monitoring is enabled or disabled for this session, or empty if status is unknown.
Data used to perform the check.
Full name used during the check.
Birth year used during the check.
List of watchlists against which the check was performed. Available only for enhanced AML solution.
List of countries associated with the check. Available only for enhanced AML solution.
Indicates whether the name used in the check required an exact match. Available only for enhanced AML solution.
Name match sensitivity on a 0–100 scale, indicates how much variation should be allowed from the end-user's data in the results. Available only for enhanced AML solution.
Indicates whether deceased individuals were excluded from the check. Available only for enhanced AML solution.
Total number of hits returned from the check.
Timestamp indicating when the check response was received.
As combined ISO 8601 date and time in UTC. Format: YYYY-MM-DDTHH:MM:SS.sssZ.
Array of records that were matched. Empty array if no hits were found.
Unique identifier of this hit. Use this ID when updating hit review status via the PATCH endpoint.
Review decision for this specific hit.
Risk level assessment for this hit. Only present when hit-level matchStatus is true_match.
Indicates whether you have whitelisted this hit. When true, ongoing monitoring no longer sends you updates for this hit. Returned as false when the hit is not whitelisted.
Reviewing a hit as false_positive whitelists it automatically.
The name that was matched in this hit based on the search term.
List of countries that the sources listed in relation to this hit.
Birth date of the person in the matched listings.
Death date of the person in the matched listings.
Array that shows the match type in the listings.
See the data provider's documentation for more detailed info.
Array of names that the matched person is also known as.
Array of names that the matched person is associated with.
Matched listings. Empty object if addon "PEP & Sanctions check" is not enabled.
Array of warning-related listings.
Source name of the related listing.
Source URL of the related listing.
Date of the related listing.
Array of sanctions-related listings.
Source name of the related listing.
Source URL of the related listing.
Date of the related listing.
Array of fitness and probity-related listings.
Source name of the related listing.
Source URL of the related listing.
Date of the related listing.
Array of PEP-related listings.
Source name of the related listing.
Source URL of the related listing.
Date of the related listing.
Array of adverse media-related listings.
Source name of the related listing.
Text snippet from the source listing.
Source URL of the related listing.
Date of the related listing.
API request status.
Identifiers of the affected session and confirmation that monitoring is disabled.
UUID v4 which identifies session attempt.
UUID v4 which identifies session.
The unique identifier that you created for your end-user. It can be max 1,000 characters long and contain only non-semantic data that can not be resolved or used outside your systems or environments. Veriff returns it unmodified in webhooks and API response payloads, or as null if not provided.
Confirms that ongoing monitoring has been disabled for this session.
Bad request - validation error
Validation error
Response when request includes invalid parameters
{
"status": "fail",
"code": "1104",
"message": "Request includes invalid parameters"
}Risk level without true match
Returned when riskLevel is sent with a matchStatus other than true_match, or on its own for a hit that is not already reviewed as true_match.
{
"status": "fail",
"code": "1104",
"message": "Request includes invalid parameters"
}Validation error
Response when request includes invalid parameters
{
"status": "fail",
"code": "1104",
"message": "Request includes invalid parameters"
}Invalid hit ID
{
"status": "fail",
"code": "1104",
"message": "Invalid hit ID"
}Un-whitelisting a false positive hit
Returned when isWhitelisted: false is sent for a hit reviewed as false_positive, or together with matchStatus: false_positive.
{
"status": "fail",
"code": "1104",
"message": "A false_positive hit cannot be un-whitelisted"
}Monitoring already disabled
{
"status": "fail",
"message": "Watchlist screening was already disabled"
}Unauthorized - invalid or missing authentication credentials
Missing X-AUTH-CLIENT header
{
"status": "fail",
"code": "1101",
"message": "Mandatory X-AUTH-CLIENT header containing the API key is missing from the request."
}Missing or invalid X-HMAC-SIGNATURE header
{
"status": "fail",
"code": "1815",
"message": "Could not authenticate request."
}Watchlist screening feature is not enabled for your integration
Verification session not found
{
"status": "fail",
"code": "1101",
"message": "Resource not found"
}Internal server error
{
"status": "fail",
"message": "Something went wrong"
}API request status
Details about the error while disabling watchlist screening
Changelog
Date | Description |
|---|---|
Sep 30, 2026 |
|
Jul 8, 2026 | Two new operations added to the endpoint: review a hit and acknowledge monitoring changes, including relevant request and response examples. |
Apr 24, 2026 | Headers capitalization harmonized |
Mar 9, 2026 | Documentation updated: parent categories rearranged, intro section expanded, request and response examples added |
Feb 16, 2026 |
|
Jan 6, 2026 | Documentation published |