Global Data Check API

POST
/globaldata_check
LIVE

The most detailed identity-matching endpoint in the platform. You send a person's identity attributes (names, address parts, DOB, up to four phones and four emails) and it returns a per-field outcome map for every input. Supports a graded match ladder (exact / alias / partial / fuzzy), multi-candidate responses, error tolerance, and configurable per-name matching policies. Use it when you need to know not just whether identity matched, but exactly how.

calendar_today Request a Demo Contact Sales

Example Request

POST
request.json
key Auth: BearerAuth 
{
  "first_name": "John",
  "middle_name": "James",
  "last_name": "Doe",
  "birth_date": "1990-01-01",
  "full_address": "4/123 Fake Street, Fakeville VIC 3987",
  "phone": "0400123456",
  "email": "john@example.com",
  "first_name_matching": ["exact", "alias"],
  "return_multiple_candidates": false,
  "ignore_errors": false,
  "include_deceased": false
}

Request Schema

last_name
Required
string

The only required field. Everything else is optional.

first_name middle_name
Optional
string

Optional name parts. Match outcomes graded as match, alias_match, partial_match, fuzzy_match, or no_match.

birth_date
Optional
date · YYYY-MM-DD.

Date of Birth.

gnaf_id
Optional
string · GAVIC421647320 or GANT_717247498

GNAF identifier. Mutually exclusive with full_address and the address parts.

full_address
Optional
string

Free-text address. Mutually exclusive with gnaf_id and the parts.

street_address suburb state postcode
Optional
string

Individual address parts. Any combination can be supplied. They don't all have to be there together.

phone phone2 phone3 phone4
Optional
string · 0NSN or E.164 format

Up to four phones (with or without leading +).

email email2 email3 email4
Optional
string

Up to four emails.

return_multiple_candidates
Optional
boolean

Return up to five best-first candidates instead of a single best.

ignore_errors
Optional
boolean

Soft-drops fields that fail validation and reports them as not_used instead of failing the request with a 400.

include_deceased
Optional
boolean

Include deceased records in the candidate pool. Defaults to false.

first_name_matching
Optional
array · Default ["exact"].

Accepted match types for first_name: exact, alias, partial, fuzzy.

middle_name_matching
Optional
array · middle_name does not gate candidates.

Same options for middle_name.

last_name_matching
Optional
array · Exact or fuzzy.

Adding fuzzy widens the candidate search to metaphone-equivalent surnames sharing a leading letter

Available Response Data

10 Data Points
01
fact_check

match_results: array of candidate rows

one row by default, up to five with return_multiple_candidates

02
fact_check

Per-row first_name: match, alias_match, partial_match, fuzzy_match, or no_match

03
schedule

Per-row middle_name: includes no_record when the candidate has no middle on file

04
fact_check

Per-row last_name: match, fuzzy_match, or no_match

05
fact_check

Per-row dob: match, match_year, match_day_month_reversal, no_record, or no_match

06
fact_check

Per-row address rollup: match, match_street, match_locality, or no_match

07
monitor_heart

Per-row component address outcomes (street_address, suburb, state, postcode) for the parts you supplied

08
monitor_heart

Per-row phone, phone2, phone3, phone4 outcomes

each one evaluated independently

09
monitor_heart

Per-row email, email2, email3, email4 outcomes

each one evaluated independently

10
fingerprint

API reference UUID

lock Full API documentation provided after vetting from our compliance team.
By The Numbers

API Data Scale & Coverage tag

Unmatched data depth to power your compliance and verification workflows.

50M+
Phone & Email Records
40M+
Adverse Court Records
2BN+
Australian Universe Records
18M+
Real Estate Records
7M+
Deceased Records
980M+
Social Media & Employment Records
Practical Applications

Technical Use Cases tag

verified_user

KYC identity verification

Replace a point-in-time DVS-only KYC with a richer match outcome. Knowing exactly how identity matched (full match vs phone-only vs address-only) lets you build risk-graded onboarding journeys.

phone_iphone

Contact validation at scale

Validate that a customer's phone, email and address all correspond to the same person in the universe. Surfaces mismatches and potential fraud before they get baked into your customer record.

cleaning_services

Customer record reconciliation

Reconcile stale or inconsistent customer records by matching them against the universe and surfacing what's changed: address moves, phone changes, name changes.

psychology

Risk-graded auto-approval logic

Use the per-field outcomes to build routing rules. Auto-approve when last_name plus DOB plus any phone match. Route to human review when only last_name and address-street match. Reject when nothing meaningful matches.

Trust & Assurance

Compliance & Security tag

Enterprise-grade infrastructure audited against the standards your regulators require.

verified_user
ISO 27001 Certified
enhanced_encryption
AES-256 Encryption
public
Australian Data Sovereignty
Integration & Support

Common Questions tag

Everything you need to know about implementation details and compliance infrastructure.

rocket_launch Implementation

What's the first_name match ladder?

add

Five levels. Strongest applicable is returned. match (exact after normalisation), alias_match (Bob / Robert, Jenny / Jennifer), partial_match (one side is a single-letter initial matching the other’s first letter), fuzzy_match (same metaphone code and leading letter), no_match. Which levels are accepted is controlled by first_name_matching.

rocket_launch Implementation

How does the address rollup work?

add

match means every supplied component matched (only the parts you supplied are evaluated). match_street means the same street number on the same street name, but a different suburb, postcode or state. match_locality means state matches plus at least one of suburb or postcode (state has to be supplied for this level). no_match is everything else.

rocket_launch Implementation

Why are there four phone and email slots?

add

Each slot is evaluated independently. If you supply phone and phone3, you’ll get a separate match or no_match for each, telling you whether that specific value matches any phone on the candidate’s file. Slots you don’t supply are left out of the response.

rocket_launch Implementation

How are candidates ranked when several match?

add

Three steps. First, strong-discriminator hits rank first (exact phone, email, full DOB, or full address). Second, within that group, exact last-name beats fuzzy last-name. Third, a weighted score breaks remaining ties (first_name match is worth 20, last_name match 12, DOB 10, address 8, each phone slot 4, each email slot 2, with lower weights for partial outcome

gavel Compliance

What does ignore_errors actually do?

add

Soft-drops individual fields that fail validation (a malformed phone, an invalid email, an unresolvable address, a junk DOB) and reports them as not_used in the response. Saves the round-trip of a 400 and a retry. Useful when consuming dirty source data.

gavel Compliance

Are deceased records included?

add

No by default. Set include_deceased: true to include them. The response doesn’t flag returned candidates as deceased, so only enable it when your downstream workflow handles deceased records properly.

Try it Live

API Testing Sandbox tag

Test the Global Data Check API directly in your browser with live mock data and see instant results.

rocket_launch Request Sandbox Access

Access to live sandbox environments requires manual approval from our compliance team.

(03) 9948 4089
Request a Demo
BACK TO TOP