WatchEye · Adhoc Checks

Launch adhoc screening checks

Launching adhoc screening checks queues one or more screening operations against a subject supplied in the request body, with no program or entity record. The call returns a 202 with the adhoc check UUID and the screening runs in the background. It uses the same operations, configuration and results as entity checks.

The same eleven screening operations as entity checks, run once against details you send in the request
Every required field is validated before any check row is created or any credit is charged

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
Required data fields per operation

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 a subject once, without adding them to a program

Not every screen belongs to an entity you monitor. A prospect, a one-off counterparty or a name from a form can be screened as an adhoc check: the subject travels in the request, the check runs in the background, and the result is read from Show an adhoc check. The response shape is the same as an entity check, so one integration reads both.

Which checks are running

The response carries the adhoc check UUID, 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.

That the subject was complete before anything was charged

The required keys in the data object depend on the operations requested, and each operation validates the same data object independently. A missing or malformed field returns 400 naming the offending key, before any check row is created or credit charged.

That entitlement and credit were checked first

A check type not enabled for the account returns 403 and insufficient credit for the total projected cost returns 402, both before anything is queued.

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; 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 an adhoc check with the UUID until the status is complete or failed, then reads the outcome and the results overview.

Subject kinds are not mixed: for a PEP and sanction check exactly one of an individual, a business name or a vessel name is supplied, and a business name sent together with a first name is rejected. Dates of birth are accepted as YYYY-MM-DD or DD/MM/YYYY.

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 Adhoc Checks

Show an adhoc check reads the results. List adhoc checks finds them. Download an adhoc check as PDF produces the report. Launch screening checks against an entity runs the same operations against an entity you monitor.

Delete an adhoc check Download an adhoc check as PDF List adhoc checks Show an adhoc check

All WatchEye adhoc checks endpoints

Questions

Questions we get asked about adhoc screening checks

Do we need a developer to implement this?

Yes. The launch is a REST call that carries the subject and queues the work, 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?

A check_types array naming one or more operations, a data object carrying the subject, and an optional config object. The required data keys depend on the operations: for a PEP and sanction check an individual needs a full name or a first and last name, a business needs a business name and a vessel needs a vessel name, with a date of birth and country optional. Adverse media requires a country. The data fields guide lists every operation.

What comes back?

A 202 with the adhoc 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.

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. Validation, entitlement and credit are all confirmed before anything is queued or charged.

How is this different from an entity check?

An entity check reads the subject from the saved entity record and belongs to a program, so monitors can re-run it and its events sit against the entity. An adhoc check carries the subject in the request, belongs to no program or entity, and records who launched it: a portal user or an API key.

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.

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