WatchEye · Checks

Show a check

Show a check returns one screening check by its UUID. It carries the same envelope as the list, with the program, entity, status, outcome and timestamps, plus the three things the list leaves out: a uniform results overview, the child summaries for a group check, and the typed details block for the operation that ran.

One row per result with a title, a status of pass, warning or fail, and the alert identifiers that tie it to events
The typed details block for the operation, so match-level data is read without a follow-up request

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 a screening check found, match by match

A launch tells you a 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. 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, such as Found 2 PEP matches, and the events count says how many events were raised.

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. Those identifiers match the check result identifiers on the related events, so a triage decision can be traced back to the match that caused it.

The full detail for the operation

The details block is typed per operation and holds the match-level data. A group check returns details as null and a children array of per-child summaries; each child is fetched with this endpoint to read its own details.

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 check that has been soft-deleted 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 Checks

Launch screening checks against an entity starts the check this call reads. List checks finds it. Download a check as PDF produces the printable report. Show an adhoc check reads a check that ran without an entity.

Download a check as PDF Launch screening checks against an entity List checks

All WatchEye checks endpoints

Questions

Questions we get asked about reading a 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 check UUID in the path, as returned by the launch or the list. Nothing else.

What comes back?

The check envelope with its UUID, check number, type and display name, status, failed reason, outcome, check summary, data summary, timestamps, program, entity, parent UUID and events count; 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 such as Match 1: John Smith - PEP, 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.

How do we read a group check?

The parent returns details as null and a children array with each child's UUID, check number, type, status, failed reason, outcome, check summary and checked at time. Fetch each child by its UUID with this endpoint to read its results overview and typed details.

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