WatchEye · Adhoc Checks

Show an adhoc check

Show an adhoc check returns one adhoc screening check by its UUID. It carries the same envelope as the list, including who launched it, plus the uniform results overview, the child summaries for a group check, and the typed details block for the operation that ran. The details use the same per-operation schemas as entity checks.

One row per result with a title, a status of pass, warning or fail, and the alert identifiers
The typed details block for the operation, in the same shape as an entity check

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 details schemas

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

Reading what an adhoc screen found, match by match

A launch tells you the check was queued. This call tells you what happened. Your system polls it until the status is complete or failed, then reads the outcome, the results overview and the details in one response.

Where the check is

The status runs pending, processing, then complete or failed. A failed check carries a short failed reason, and the checked at timestamp is set once the check has run.

Whether anything needs review

The outcome is pass when nothing was flagged and warning when one or more matches should be reviewed. The check summary states the result in a sentence and the data summary restates the subject.

Each result on its own

The results overview has one row per result with a title, a per-result status and the provider alert identifiers. The typed details block holds the match-level data for the operation; a group returns details as null and a children array to fetch one by one.

Who ran it

The record says whether the check was launched by a portal user or by an API key, and which one, so a one-off screen can be attributed in an audit.

How a check runs

The launch queues the work; this call carries the answer

Screening runs in the background after the launch returns 202. Repeat this call with the same UUID until the status is complete or failed, then read the outcome, the results overview and the details.

Poll every 2 to 5 seconds for the first 30 seconds, then every 15 to 30 seconds. A printable PDF of the same check is available from the PDF download endpoint. A soft-deleted adhoc check returns 404.

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. The results overview is empty or every row is pass. 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

Launch adhoc screening checks starts the check this call reads. List adhoc checks finds it. Download an adhoc check as PDF produces the printable report. Delete an adhoc check removes it.

Delete an adhoc check Download an adhoc check as PDF Launch adhoc screening checks List adhoc checks

All WatchEye adhoc checks endpoints

Questions

Questions we get asked about reading an adhoc check

Do we need a developer to implement this?

Yes. This is a REST read by UUID, and the details block differs by operation, so a developer maps the shapes your system needs. 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 adhoc check UUID in the path, as returned by the launch or the list. Nothing else.

What comes back?

The adhoc check envelope with its UUID, check number, type, status, failed reason, outcome, check summary, data summary, timestamps and who created it; the results overview array; the children array for a group; and the typed details block for the operation.

What is in the results overview?

One row per result. Each has a short title, a status of pass, warning or fail, and the alert identifiers the row generated. Fail is used by email and phone checks for undeliverable or disconnected entries. The array is empty for group checks and for operations that return everything in a single record.

Is reading a check billed?

No. The charge is made when the check is launched. Reading it, listing it and downloading the PDF are not billed.

What if the check has been deleted?

Soft-deleted records return 404 from this endpoint and are no longer returned by the list. They remain in the database for compliance and audit purposes and can be restored in the portal within 30 days.

What happens to the personal information in the response?

Personal information stored in WatchEye is covered by Global Data's security policies for the platform. Once your integration copies it into your own applications, databases, logs or backups, protecting it becomes your responsibility. Retrieve only the fields you need and treat any logs that capture API payloads as sensitive.

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