WatchEye · Checks

Launch screening checks against an entity

Launching screening checks queues one or more screening operations against an entity already saved in a WatchEye program. The call returns a 202 with the check UUID and the screening runs in the background. Results are read from Show a check once the status is complete, and any matches raise events in the triage queue.

Eleven screening operations, from PEP and sanction to court, business, real estate and adverse media, launched singly or as a group in one call
Each check type is charged at launch and refunded if the provider fails; entitlement and credit are confirmed before anything is queued

Request access Talk to sales

For developers

After the technical detail?

For the technical detail, go to the API documentation. It holds the request and response schema, the integration guides and the error codes for this endpoint.

Request and response schema
Per-operation configuration and defaults

Go to the API docs

New accounts begin with sandbox access.

ISO 27001 certified Handled under Australian privacy law Every API call written to the audit log

What the check gives you

Screening an entity you already hold, without re-keying its details

The entity record carries the names, dates, numbers and addresses the screening operations read, so the request names the entity and the check types and nothing else. A single check type returns that check. Two or more return a parent group check with one child per type, each queued and pollable on its own.

Which checks are running

The response carries the check UUID, a short check number, a status of pending and the path to poll. A group launch lists each child with its own UUID, status, resolved configuration and detail path, in the order requested.

What each check is running with

Where an operation takes configuration, the response echoes the resolved values: defaults merged with anything you supplied. For PEP and sanction that is the search strictness, the similarity threshold, the PEP and sanction countries, the maximum results and whether extended detail is included.

That nothing was charged for a request that could not run

The request is validated before any check rows are created or credit is charged. An unknown entity returns 404, a missing or unknown check type 400, a check type the account is not entitled to 403, and insufficient credit for the total projected cost 402.

That a retry will not double the work

An optional Idempotency-Key header makes retries safe. The same key and body returns the original response with an Idempotent-Replay header, and the background work is not queued twice. The same key with a different body is rejected with 422.

How a check runs

Accepted at once, screened in the background, read when complete

The launch returns 202 as soon as the checks are queued. Your system polls Show a check with the UUID until the status is complete or failed, then reads the outcome and the results overview. Most screening checks complete within a few seconds.

The documented polling cadence is every 2 to 5 seconds for the first 30 seconds, backing off to every 15 to 30 seconds. A group check stays at processing while any child is still running, is failed if any child failed, and is complete once every child is complete.

Reading the result

What each answer means for the record in front of you

The status field says whether the check has finished. Once it is complete, the outcome field says whether anything needs your attention.

Pass

Nothing was flagged

The check completed and no result needs review. For a PEP and sanction screen that means no match above the similarity threshold. The check summary states the result in a sentence, and the events count is zero.

Warning

One or more matches need review

The check completed with results to look at. Each row in the results overview carries a title, its own status of pass, warning or fail, and the alert identifiers that link it to the events raised in the triage queue.

Failed

The check could not be completed

The upstream provider returned an error. The failed reason is recorded on the check and the credit charged at launch is refunded. Launch the check again once the cause is understood.

What it costs

Charged per check type, at launch, against your account balance

Each screening check type you launch is charged to your WatchEye account when the request is accepted. The rate for each check type is set for your account and communicated by your Global Data account manager. Statements with a breakdown of API calls and their costs are available in the WatchEye portal.

Billed at launch
Refunded if the provider fails

How billing works

Credits drawn down as each check is queued

Each check type in the request is charged when the launch is accepted.
If the upstream provider returns an error, the check is marked failed and the credit for that check is refunded.
A 402 response means the account has reached its credit or call limit. Nothing is queued and nothing is charged.
Reads, lists and PDF downloads are not billed.

Talk to us about rates

Related checks

Others in WatchEye Checks

Show a check reads the results. List checks finds them across the account. Download a check as PDF produces the report. Launch adhoc screening checks runs the same operations against a subject with no entity record.

Download a check as PDF List checks Show a check

All WatchEye checks endpoints

Questions

Questions we get asked about launching screening checks

Do we need a developer to implement this?

Yes. The launch is a REST call that queues the work and returns a UUID, and a second call reads the result, so a developer connects the two-step flow to your system. A sandbox account is available for development at no charge. It is a separate account with its own API keys, it returns test data in the same response shapes as live, and the same base URL serves both environments.

What does our system need to send?

The entity UUID in the path and a check_types array naming one or more operations. A config object is optional. Each configurable operation has documented defaults that apply when its key is omitted, so a block is only needed to override a default. Adverse media, phone, email, ADC and ADC custodian checks take no configuration.

Which screening operations can be launched?

PEP and sanction, banned and disqualified persons, court, Australian business, UK business, real estate, adverse media, ADC, ADC custodian, phone and email checks. The entity record supplies the subject details each operation needs.

What comes back?

A 202 with the check: its UUID, check number, type, a status of pending, the resolved configuration for a single-type launch, and the detail path to poll. A multi-type launch returns the parent group check with a children array carrying the same fields for each child.

How long does it take?

Most screening checks complete within a few seconds. Poll the show endpoint every 2 to 5 seconds for the first 30 seconds, then every 15 to 30 seconds, until the status is complete or failed.

What does it cost?

Each requested check type is charged at launch. If the upstream provider returns an error, that check is marked failed and its credit is refunded. Entitlement and credit are confirmed before anything is queued: a check type not enabled for the account returns 403 and insufficient credit returns 402, with nothing charged.

What if the connection drops after we send the request?

Send an Idempotency-Key header, typically a fresh UUID per logical request. A retry with the same key and body returns the original response verbatim, marked with an Idempotent-Replay header, and the checks are not queued or charged a second time. A successful response is remembered for 24 hours.

How do we test it?

Against a sandbox account. Sandbox calls are not charged, screening operations return canned test data, and the response shape is identical to live so your code does not branch on environment. The sandbox guide lists the names, numbers and identifiers that produce each outcome.

Getting started

The first step to access is a conversation

Sandbox accounts are provisioned by your Global Data account manager. API keys are created and managed in the WatchEye portal, and the same endpoints serve sandbox and live; the account behind the key decides which environment you are in.

Request access Talk to sales

Call 03 9948 4089, 9am–5pm AEST Monday to Friday

ISO 27001 certified

Handled under Australian privacy law

Every API call written to the audit log