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 · Adhoc ID Checks

Launch an adhoc ID check

Launching an adhoc ID check runs a synchronous identity verification against details supplied in the request, with no program or entity record, and returns the completed check in the same response. It uses the same fourteen DVS types and five non-DVS sources as an entity check, carries the same consent assertion, and records whether a portal user or an API key launched it.

  • The same document types and sources as an entity ID check, with nothing to set up first
  • The outcome of pass or fail is final when the response arrives
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-type input fields and consent obligations
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

Verifying an identity document once, without creating an entity

Not every verification belongs to a monitored entity. A one-off applicant, a counter-party or a walk-in can be verified as an adhoc ID check: the details travel in the request, the result comes back inline, and a certificate is available for the file.

Whether the document verified

The outcome is pass or fail, with a one-line outcome summary and a data summary of what was checked. Document numbers are never returned.

What the source said

The typed details block carries the source's own result for the type, such as a DVS verification result code with any additional information behind a not-verified answer.

Who ran it

The record says whether a portal user or an API key launched the check, with the username or the key label, so a one-off verification can be attributed in an audit.

That the launch was safe to retry

An optional Idempotency-Key header returns the original response on a retry with the same key and body, so a dropped connection cannot run or charge the check twice.

How a check runs

Sent to the issuer and answered in the same response

Your system sends the document details with the consent assertion. WatchEye verifies them with the upstream source and returns the completed check with its outcome. Nothing is queued.

Names take up to 50 characters of letters, spaces, apostrophes, hyphens and full stops. Dates are YYYY-MM-DD; month-only card expiries are YYYY-MM. State codes are ACT, NSW, NT, QLD, SA, TAS, VIC or WA.

Reading the result

What each answer means for the record in front of you

ID checks run synchronously, so the outcome in the response is final. The one exception is a check completed through an IDPass, which stays pending until the individual finishes the hosted link.

Pass

The identity was verified

The supplied details were verified by the upstream source. The outcome summary states the result in a sentence, the verification details list what was checked, and the typed details block carries the source's own result, such as a DVS verification result code of Y.

Fail

The details did not verify

The upstream source did not verify the supplied details. For a DVS check the details block carries the result code and any additional information the issuer returned. The check is complete and can be downloaded as a certificate.

Pending

An IDPass is still with the individual

Only an ID check satisfied by an IDPass reports pending. The response embeds the IDPass shell with its status and hosted link; follow the IDPass path and poll it until the status is terminal.

What it costs

Charged per check, after the upstream verification call

Each ID check launch is charged to your WatchEye account at run time, after a successful call to the upstream verification source. 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 per check
  • Consent asserted on every launch
How billing works
Credits drawn down against your account balance
  • A launch is charged after the upstream verification call succeeds.
  • An entitlement the account lacks returns 403 and nothing is charged.
  • A 402 response means the account has reached its credit or call limit. Nothing is run and nothing is charged.
  • Reads, lists, PDF certificates and images are not billed.
Talk to us about rates
Related checks

Others in WatchEye Adhoc ID Checks

Show an adhoc ID check reads the result again. List adhoc ID checks finds them. Download an adhoc ID check certificate as PDF produces the certificate. Launch an ID check against an entity runs the same verification for a person you monitor.

Questions

Questions we get asked about adhoc ID checks

Do we need a developer to implement this?
Yes. The launch is a single REST call that returns the completed check, so a developer connects it to the point where the document details are collected. 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?
No entity is named. The id_type to run, consent_obtained set to true, and a data object with the fields that type needs, such as the document number, names, the birth date in YYYY-MM-DD format and the issuing state. Document numbers are never returned in responses. An oac code is required when the account has more than one DVS Originating Agency Code configured.
Which identification types can be run?
Fourteen DVS types: driver licence, passport, Medicare card, visa, birth certificate, Centrelink card, ImmiCard, AEC enrolment, ASIC or MSIC card, citizenship certificate, death certificate, marriage certificate, change of name certificate and registration by descent. Five non-DVS types: Global Data, ASIC ID check, New Zealand driver licence, New Zealand passport, and payroll and super. One type per launch; MultiCheck is not available through the API in v1.
What does consent_obtained commit us to?
That your system presented consent wording to the individual before the launch, that they accepted it, and that you have retained the exact wording with the time and identity of the individual and can produce it on request. WatchEye records a generic attestation against the check; the authoritative record lives in your system. For DVS types the wording must align with your DVS Agreement with the Australian Government. A request with consent_obtained false or omitted is rejected with 400.
What comes back?
A 200 with the completed check: its UUID, check number, id type and check type with display names, the outcome, an outcome summary, a data summary, the checked at time, who created it, the consent attestation, the verification details and the typed details block for the type.
What does it cost?
Each launch is charged at run time after a successful upstream verification call. A type the account is not entitled to returns 403 and insufficient credit returns 402, with nothing charged.
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 check is not run or charged a second time. A successful response is remembered for 24 hours, and the same key with a different body is rejected with 422.
How do we test it?
Against a sandbox account. Sandbox calls are not charged and the response shape is identical to live, so your code does not branch on environment. For DVS types the sandbox outcome is driven by the document number: numbers starting with 1 match, with 2 return invalid and with 3 return not matched, and listed magic numbers produce specific not-matched reasons. A surname starting with error simulates an upstream system error.
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