WatchEye · Monitors

Create a monitor

Creating a monitor sets up a scheduled or on-demand screening job in a program. It runs one screening operation, fixed at creation, against the entities in the program on the schedule you choose, with the operation's configuration supplied in the request. The call returns 201 with the monitor.

One operation per monitor, from PEP and sanction to business, court, adverse media and contact checks
Fifteen schedules from daily to quarterly, or manual for runs you trigger yourself

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
Fields, schedules and per-operation configuration

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

Turning a one-off screen into ongoing monitoring

A check answers the question once. A monitor keeps asking it: every day, every weekday, on the first of the month, or whenever you trigger it, across every entity in the program. Each match it finds becomes an event in the triage queue.

What it screens for

The monitor check type names the operation and must be one enabled on the account. It cannot be changed after creation; a different operation means a new monitor.

How it is configured

The config object is per operation. Every required key for the operation must be supplied; a missing key returns 400 with the validation errors. Defaults and allowed values are documented per operation.

When it runs

The schedule sets unattended runs, and a status of active lets it run on schedule and on demand. A paused monitor does neither.

That a retry will not create a second monitor

An optional Idempotency-Key header returns the original response on a retry with the same key and body. A key reused with a different body is rejected with 422.

How a check runs

Where monitors sit in the WatchEye model

A monitor is set on a program and runs one screening operation against every entity in it, on a schedule or on demand. New matches appear in the events queue for triage.

Entities not eligible for the operation are skipped and not billed.

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 Monitors

Run a monitor on demand triggers it now. Show a monitor reads its state. Update a monitor changes its configuration, name, status or schedule. List events shows what its runs have raised.

Delete a monitor List monitors in a program Run a monitor on demand Show a monitor Update a monitor

All WatchEye monitors endpoints

Questions

Questions we get asked about creating a monitor

Do we need a developer to implement this?

Yes. This is a single REST call that returns the created monitor, so a developer wires it to whatever sets up ongoing screening in 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?

The program UUID in the path, a monitor name of 3 to 255 characters, the monitor check type, a status of active or paused, a schedule, and a config object with every required key for the operation.

What schedules are available?

Manual, which never runs on its own; every day; weekdays; weekends; a single weekday from Monday to Sunday; the first of the month; the fifteenth; the first and fifteenth; or quarterly. A manual monitor is triggered with Run a monitor on demand.

What goes in the configuration?

Whatever the chosen operation expects. A PEP and sanction monitor takes a search type, a similarity threshold, PEP and sanction country lists, a maximum number of results and whether extended results are included. A business check takes name matching and the signals that raise an alert. Court, banned and disqualified, UK business, real estate, ADC, adverse media, email and phone monitors each have their own keys. The monitor configuration guide lists every key, its allowed values and its default.

What comes back?

A 201 with the monitor: its UUID, a short monitor number, the name, the check type with its display name, status, process status, schedule with its display name, the configuration, when it last ran, whether it has run before, the program UUID and timestamps.

What is the difference between status and process status?

Status is the lifecycle setting you control: active runs on its schedule and can be triggered manually, paused does neither. Process status is the in-flight state of a run: pending, processing, failed when the most recent run failed, paused when a run stopped mid-flight for example on credit, or null when the monitor is idle.

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 monitor is not created twice. A successful response is remembered for 24 hours, and the same key with a different body is rejected with 422.

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