Skip to content
New

Person Report API and New Zealand identity checks are now live.

See what's newarrow_forward
WatchEyeOnboarding & monitoring

Customer onboarding, screening and ongoing monitoring in one system, with real-time KYC and KYB alerts when a customer's risk changes.

Visit WatchEyearrow_forwardcheck_circleIncluded in the Global Data Portal
IDFEX ID CheckIdentity verification

One-to-one identity, document and data checks against the DVS and Australian data sources, run from the Portal or by API.

Visit IDFEX ID Checkarrow_forwardcheck_circleIncluded in the Global Data Portal
ID PassSelf-service verification

Customers verify their own identity and biometrics from a link on their phone. The result comes back to you, and they keep control of their data.

Visit ID Passarrow_forwardcheck_circleIncluded in the Global Data Portal
InsiightData quality

Verifies, corrects and enriches customer records so they stay accurate — one at a time or across your whole database.

Visit Insiightarrow_forwardcheck_circleIncluded in the Global Data Portal
Australian Death CheckDeceased data

The official national death data source. Match your records against it to find and remove deceased individuals.

Visit Australian Death Checkarrow_forwardcheck_circleIncluded in the Global Data Portal
QuesterMarketing lists

Build targeted, privacy-compliant Australian marketing lists with smart filters. Pay only for the records you download.

Visit Questerarrow_forwardcheck_circleIncluded in the Global Data Portal
verified_userVerify Identities7 solutions

Confirm a person or business is who they claim to be: government IDs, biometrics, business registries and employment checks against authoritative Australian sources.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
policy_alertScreen & Monitor7 solutions

Meet AUSTRAC obligations and understand customer risk: screening, risk assessment, fraud controls and investigation tools with evidence recorded for each check.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
databaseImprove your data3 solutions

Keep customer records accurate and put them to work: correct and enrich existing data, unify it into a single view, or build compliant marketing lists from opted-in records.

All solutionsarrow_forwardcheck_circleAvailable in the Portal and by API
monitoringWatchEye API14 categories

The WatchEye API gives programmatic access to everything in WatchEye: PEP and sanctions screening, identity checks, IDPass verifications, monitoring programs, events and reports.

View allarrow_forwardcheck_circleSandbox environment for integration testing
policyAML & screening5 use cases

Obligations under the AML/CTF Act, from screening at onboarding through to ongoing monitoring — with the evidence for each check recorded.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
how_to_regOnboarding & identity3 use cases

Verifying who a customer, employee or account holder is — at sign-up and during ongoing checks — against authoritative Australian sources.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
databaseData & enrichment4 use cases

Keeping customer records accurate, current and complete: validate contact detail, fill the gaps, locate people and remove deceased records.

All use casesarrow_forwardcheck_circleMapped to the products and data that cover it
Global Data
Portalarrow_forward
Productsexpand_more
Solutionsexpand_more
Use casesexpand_more
Dataexpand_more
APIarrow_forwardIndustriesarrow_forwardResourcesarrow_forwardAboutarrow_forwardContactarrow_forward Request a Demo
Talk to the team

9am–5pm AEST, Monday to Friday.

call03 9948 4089
WatchEye · Events

List events

List events returns the triage queue: each event is a thing your team should look at, produced by a screening check, such as a PEP or sanction match, a phone or email match or an adverse media hit. Events carry a lifecycle status from new through investigating to a closure with a reason, and filters narrow the queue by status, check type, entity, program, check and date.

  • Every event on the account, 30 per page by default and up to 500, newest first
  • Filter by status, check type, entity, program, originating check, date range and archive state
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

Working the queue of matches that need a decision

Screening produces matches; someone has to decide which are real. The events list is that queue: what is new, what is being investigated, and what was closed and why. A case system pulls new events from it and writes decisions back with Update an event.

What each event is about

The check type that produced it, a check summary of what was searched, the entity and program it belongs to, the originating check UUID, and the check result identifiers that point at the underlying match data.

Where it is in triage

The status of new, investigating or one of the four closures, and how many notes are attached.

How it was grouped

Under separate grouping the check response index says which match in the parent check the event represents. Under grouped, it is null and the event aggregates every match for the entity.

Only the events you asked for

Filter by status, check type, entity, program, check, and created between two times. The archived parameter selects archived or non-archived events. Sort by created at or status.

How a check runs

How an event moves through triage

A match arrives as a new event. Someone picks it up as investigating. It is closed with one of four reasons, of which only closed confirmed means the match was real.

Events are not deleted on their own; closing sets the status to one of the closed values. A filter that targets an entity, program or check UUID that does not exist on the account returns an empty page.

Reading the result

What each answer means for the record in front of you

The status carries the triage decision. The four closures are not interchangeable: three record why a match was not real, and one records that it was.

New

Raised and not yet looked at

Screening produced a match that someone should review. The check summary says what was searched, the check result identifiers point at the underlying match data, and the notes count is zero until someone writes one.

Investigating

Someone is working it

A person or an integration has picked the event up. Notes attached along the way record what was found, and the event stays here until it is closed with a reason.

Closed confirmed

The match was real and acted on

The only closure that means the screening found something true. The other three, dismissed, duplicate and error, record why the match did not stand, which is the reporting value of the queue.

What it costs

Charged when screening runs, not when records are managed

Charges arise when screening runs against the entities in a program: each check type launched against an entity is charged at launch, and a monitor run is charged for each entity eligible for its operation. Rates are set for your account and communicated by your Global Data account manager, and statements with a per-call breakdown are in the WatchEye portal.

  • Billed per screening operation
  • Refunded if the provider fails
How billing works
Credits drawn down against your account balance
  • A screening check is charged per check type when it is launched, and refunded if the provider fails.
  • A monitor run bills only for the entities eligible for its operation; a UK check skips businesses outside the UK, for example.
  • A run that would exceed the account's credit is refused with 402 and a billing breakdown, before anything is queued.
  • Reads, lists and PDF downloads are not billed.
Talk to us about rates
Related checks

Others in WatchEye Events

Show an event reads one event with its notes. Update an event moves it through triage and attaches notes. Show a check reads the match data an event points at.

Questions

Questions we get asked about listing events

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 case or review system works your queue. 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 status, check type, entity UUID, program UUID, check UUID, created at from and created at to, a sort field, and the archived flag.
What comes back?
A data array of events with their UUID, event number, status, check type, check summary, check response index, check result identifiers, archive and deletion timestamps, entity, program and check UUIDs, notes count and created at; a meta object with paging; and an API reference.
What are the event statuses?
New, when the event has been raised and not yet triaged. Investigating, when someone or some integration is working it. Then four closures: closed confirmed for a match that was real and acted on, closed dismissed for a false positive, closed duplicate when it duplicates another event, and closed error when it was caused by a data entry error. Only closed confirmed means the match was real.
How do we get from an event to the match behind it?
The event carries the originating check UUID and the check result identifiers. Read the check with Show a check and match those identifiers against the alert identifiers in its results overview.
How is the list ordered and paged?
Newest first by default. Sort by created at or status, with a leading minus for descending. Pages hold 30 records by default and up to 500.
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.

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