WatchEye · Adhoc Checks

List adhoc checks

List adhoc checks returns the one-off screening checks on the calling account as a paginated list. An adhoc check runs against a subject supplied in the request rather than an entity record, so each envelope carries the subject summary and who launched it: a portal user or an API key. Filters narrow the list by check type, outcome, creator, parent group and date.

Every adhoc check on the account, 30 per page by default and up to 500, newest first
Filter by who launched the check, whether a portal user or an API key, as well as type, outcome, parent and date

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
Filters, sort fields and pagination

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

Finding the one-off screens that ran outside your programs

Adhoc checks accumulate from quick checks in the portal and from integrations screening on demand. The list is how a reviewer or a reconciliation job finds them, sees who ran them, and picks out the ones with matches to review.

What ran and what it found

Each record carries the check type, the status, the outcome of pass or warning once complete, a one-line check summary and a one-line data summary of the subject that was screened.

Who launched it

The record says whether the check was created by a portal user or an API key, and which one. Filter by creator kind, by user UUID or by API key UUID to isolate one source of checks.

How much attention it needs

The events count says how many events were raised against the check. The checked at and archived at timestamps show when it ran and whether it has been hidden from the active list.

Only the checks you asked for

Filters cover check type, outcome, creator, parent, checked after and checked before. Sort by checked at, check type or outcome, ascending or descending. Group checks appear as first-class records with their children one filter away.

How a check runs

Where adhoc checks sit in the WatchEye model

An adhoc check uses the same screening operations as an entity check but belongs to no program or entity. Its matches still raise events, and every call that touches it is written to the audit log.

A filter that targets a parent, user or API key UUID returns an empty page when that UUID does not exist on the calling account, the same as for a UUID that does not exist at all.

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 one record with its results and details. Launch adhoc screening checks creates them. List checks covers the checks that ran against entities in your programs.

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

All WatchEye adhoc checks endpoints

Questions

Questions we get asked about listing adhoc checks

Do we need a developer to implement this?

Yes. This is a paginated REST list with query-string filters, so a developer connects it to whatever reporting or review job needs it. 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?

Nothing is required. Optional query parameters are page, per page, the filters for check type, outcome, created by, created by user UUID, created by API key UUID, parent UUID, checked after and checked before, and a sort field.

What comes back?

A data array of adhoc check envelopes, a meta object with the current page, per page, total and last page, and an API reference for the call.

How do we find the children of a group check?

Filter by parent UUID with the group's UUID. The group itself appears in the list with a check type of group.

How is the list ordered and paged?

Newest first by default. Sort by checked at, check type or outcome, with a leading minus for descending. Pages hold 30 records by default and up to 500.

Is listing billed?

No. Reads are not charged; the charge is made when a check is launched.

How many calls can we make?

The default rate limit is 600 requests per minute, enforced in a 60-second fixed window. Requests over the limit receive a 429 response, so pace requests evenly and back off before retrying. A higher limit can be arranged on a case-by-case basis.

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