Sandbox

WatchEye provides separate sandbox accounts for testing integrations without consuming live credit or touching live screening data. Sandbox is the recommended environment for all development work and continuous-integration runs.

What's different

• Separate account. Sandbox is a distinct account with its own UUID and its own API keys. The environment (live or sandbox) is fixed at the account level - you cannot switch an existing key between environments with a query parameter, header or environment variable.
• No billing. Calls made with a key on a sandbox account are not charged.
• Test data only. Screening operations return canned or test-provider data, not real PEP, sanction or business records. The response shape is identical to live so that your integration code does not need to branch on environment - only the data behind it changes.
• Same endpoints, same URL. Sandbox and live share https://portal.watcheye.com.au/api/v1. Which environment you are operating in is determined entirely by the account behind the API key you authenticate with.

How to tell which environment you are pointed at

GET /v1/account returns an environment field of either live or sandbox. This is the authoritative answer.

Getting a sandbox account

Sandbox accounts are provisioned by your Global Data account manager. Once your sandbox account exists, API keys on it are created and managed in the API Keys (login required) section of the sandbox portal in exactly the same way as keys on a live account.

Recommended workflow

1. Build and exercise your integration against a key on your sandbox account. Every endpoint, every response shape, every error envelope, idempotency and rate-limit behaviour mirrors live.
2. Run your happy-path and failure-path test suites against sandbox - as often as you like, with no billing impact.
3. Switch to a key on your live account for production. The only change in your code should be the credentials.

Sample sandbox test data

In sandbox mode the underlying data providers (DVS, ASIC, Companies House, etc.) are replaced with simulators that return deterministic results from a fixed set of test inputs. You can use any entity details you like to exercise the request and response plumbing, but to drive a particular outcome - a match, an explicit not-matched, a system error - you need to use one of the values listed below.

All of these values only produce results on keys belonging to a sandbox account. The same inputs sent to a live key reach the real upstream providers and return real (or no) data.

Screening check inputs

Sample data for screening checks is matched against the entity record (or, for adhoc checks, against the input payload). To exercise a particular outcome, create an entity with the matching details and then launch the relevant screening check against it.

pep_sanction_check

Names that produce a match in the sandbox PEP / sanction dataset:

Business / organisation matches:

Any other name returns an empty result set.

banned_disqualified_persons

The banned and disqualified persons check covers two registers: the ASIC banned and disqualified persons registers (the six banned_type values shown below) and the ATO disqualified SMSF trustees register (ato_disqualified_trustee). Each of the eight sandbox names below has one record on the ASIC side and one record on the ATO side, so an unfiltered call typically returns two matches per name. Set config.banned_disqualified_persons.banned_types to one or more banned_type values (including ato_disqualified_trustee) to scope the search to specific registers.

All three search_type values (narrow_search, medium_search, broad_search) are supported by the sandbox dataset. Any other name returns an empty result set.

business_check

The Australian business check is driven by the entity's ABN or ACN. The following sample businesses produce results in sandbox:

Any other ABN / ACN returns an empty extract.

uk_business_check

Driven by the entity's UK company number:

Any other company number returns "company not found".

court_check

Sandbox only returns matches for one person and one company:

Any other name returns zero records.

realestate_check

Driven by the entity's address. The sandbox real-estate dataset is keyed by G-NAF ID; matching addresses must resolve to one of the IDs below.

For a negative case, use G-NAF ID GAVIC419608268 - the address resolves but has zero listings, which exercises the "address found, no listings" branch.

adc_check

The ADC (Australian deaths) check returns matches for these names. Lookups use first name + middle name + last name + birth date.

Any other input returns no matches.

adc_custodian_check

The custodian variant of the ADC check returns a simple deceased / not-deceased flag. Same backend data as adc_check, so the names above also match here. The search type adjusts based on what you supply: birth date + multi-word first name forces an exact-name match; birth date + single-word first name allows a partial-name match (useful for matching records that include a middle name); death date only matches name + date of death.

Any other name returns "not deceased".

adverse_media

Adverse media requires the entity's country to match the seeded record:

People:

Businesses:

Any other input returns has_adverse_media: false.

email_check

The email-check sandbox is driven entirely by the email suffix - the local part can be anything:

Example: test@example.org returns Undeliverable; slow@example.com.au returns Deliverable after a ~20 second delay (useful for exercising your timeout handling).

phone_check

The phone-check sandbox uses a small seeded dataset. Phone numbers must be Australian and can be submitted in E.164 (+61...) or local (0...) form. Sample numbers that return data:

These same people are also useful for global-data ID checks and other lookups backed by the same sandbox dataset - see the globaldata section below.

ID check inputs

ID checks against DVS providers all follow the same convention: number ranges drive the broad result, individual magic numbers drive specific not-matched reasons, and out-of-range numbers return a random result on each request.

DVS document number ranges

For every DVS document type listed below, the document / card / certificate number is checked against a numeric range first:

The per-document tables below list the specific ranges (for example 10000000-19999999 for driver licences) and the magic numbers within them that produce deterministic not-matched reasons.

Important: if you submit a document number that falls outside any documented range and does not match a magic number, the sandbox returns a random result on each request. To get a deterministic failure use one of the specific magic numbers in the tables below; to get a deterministic match use any number in the 1... range.

Last-name overrides

The following surname prefixes override the number-based outcome for any DVS check. They are matched case-insensitively against the surname field for the document type (last_name, full_name, or - for marriage certificates - either last_name1 or last_name2).

The prefix overrides take precedence over the document-number ranges, so last_name = Errorsmith returns a system error regardless of which document number you send.

drivers_licence

The state must be VIC for the sandbox to engage. Use the licence number as both licence_number and card_number.

passport

visa

The passport_number is the foreign passport number.

medicare

asic_msic

citizenship_certificate and registration_by_descent

Both use the same stock_number ranges.

immicard

centrelink

CRN matching uses the leading digit for the range and the trailing letter for magic-number outcomes.

aec

The AEC sandbox is driven by the leading house number of street_address and by suburb instead of a document number; the rest of the address can be anything.

birth_certificate, marriage_certificate, death_certificate, name_change_certificate

The four BDM (Births, Deaths and Marriages) certificate checks share a common scheme but the certificate-number ranges depend on the issuing state and on which certificate it is.

Range plan by state:

Deterministic NOT_MATCHED magic numbers (return a fixed reason per state):

• Birth, marriage and name-change certificates:
  • ACT, NSW, NT, SA, VIC: 9999990 - 9999994 (7 digits)
  • QLD: 9999999990 - 9999999994 (10 digits)
  • TAS, WA: 99999999990 - 99999999995 (11 digits)
• Death certificates:
  • ACT, NSW, NT, SA: 9999990 - 9999994 (7 digits)
  • VIC: 99999990 - 99999993 (8 digits) - intentional outlier, follows the live VIC death-certificate format
  • QLD: 9999999990 - 9999999994 (10 digits)
  • TAS: 99999999990 - 99999999991 (11 digits)
  • WA: 99999999990 - 99999999995 (11 digits)

For VIC death certificates specifically: 99999990 = document not found; 99999991 = certificate number does not match; 99999992 = registration number does not match; 99999993 = given name does not match.

For marriage certificates the document records both parties but the request still carries a single certificate_number; the magic numbers apply to that one field regardless of which spouse's name is involved.

asic_id_check

The non-DVS ASIC ID check returns matches for these people:

Any other name returns no match.

globaldata

The Global Data identity check searches the same seeded sandbox dataset as the phone check, so any of the seeded people work as inputs. The sandbox outcome is keyed on last_name; supply the other fields the check requires (see ID Checks).

last_name of Notarealsurname (or any other unseeded surname) returns an empty match set.

nz_drivers_licence

The NZ Drivers Licence check verifies against a simulated NZTA database. Licence numbers must pass the check-digit validation regardless of the scenario being exercised.

nz_passport

The NZ Passport check verifies against a simulated DIA Passport database. Passport numbers must be in the valid NZ format regardless of the scenario being exercised.

payroll_super

The non-DVS payroll & superannuation check returns matches for these people. Address, email, phone and employer-ABN inputs are also matched against the seeded record - matching values come back as MATCHED, anything else as UNMATCHED.

Reference values for the matched paths (any field that does not match the value below comes back as UNMATCHED):

John James Doe (1990-01-01)
  4/123 Fake Street, Fakeville VIC 3987 AU
  john@example.com / 0400123456 / employer_abn 12345678901

Jane Karen Smith (1995-02-18)
  456 Wrong Avenue, Sampleville NSW 2785 AU
  jane@example.com / 0412345678 / employer_abn 98765432109

Fiona Cheng (1982-06-28)
  3 Right Avenue, Hiddenville WA 6824 AU
  fiona@example.com / 0400987654 / employer_abn 91237856482

To force a 500 upstream-failure response, submit first_name = Service and last_name = Unavailable.

ID Pass verifications are exercised with document images rather than field values: see IDPass Test Documents (login required) for the sample licences and passports and the result each one returns.