Passport
Visa
Driver License
Medicare Card
Citizenship Certificate
Centrelink Card
Immigration Card
Birth Certificate
Death Certificate
Marriage Certificate
Change of Name Certificate
ASIC/MSIC Card
AEC Electoral
How sandbox works
Sandbox is a property of your company account, not of the URL. When your account is in sandbox mode, the same production endpoints stop calling the real upstream source and answer from stored fixtures instead. Same URLs, same tokens, same authentication. Sandbox differs from live in exactly two ways:- The upstream source is never called. The response comes from a fixture.
- No credit is reserved or charged.
A sandbox response is deliberately identical in shape to a live one. There is no
sandbox or environment field to branch on — that is the point, so code you write against sandbox works unchanged in production.Going live
Nothing in your integration changes. Your account is switched to live mode and the same calls begin reaching the real sources. There is no URL or token to swap.Authentication
Use the same Bearer token you use in live:Matching rules
Your request payload must match one of the documented sandbox requests exactly to get that scenario’s response. A valid payload that matches nothing is answered as a no-match — HTTP200 with isValid set to false — the same answer the real source gives for identity data it holds no record for.
Copy the payloads from the endpoint pages to exercise the other outcomes.
Response placeholders
The sample responses on the endpoint pages use placeholders for values that change on every call:Sending metadata
metadata is ignored for fixture matching and echoed back untouched. Any scenario can be called with it:
VERIFIED sample for that endpoint, with "metadata": { "yourReference": "abc-123" } in place of null.
Date formats
All date fields areDD-MM-YYYY — for example, 29-12-1990. The one exception is cardExpiry on the ASIC/MSIC Card endpoint, which is YYYY-MM — for example, 2030-01. Its validator enforces this strictly.
Error codes
Non-verification responses
Three responses do not use the verification envelope. They are produced before — or instead of — a verification result, so they carry noverificationStatus, verificationStatusCode, or data.
Validation failure — HTTP 400
Validation failure — HTTP 400
Returned when the request body fails field validation. This happens before any fixture matching, so it is identical in sandbox and live. Note that
transactionId is null and there is no verificationStatus.Plan not enabled — HTTP 403
Plan not enabled — HTTP 403
Returned when the authenticated company has no plan for the verification type. The plan gate is enforced in sandbox exactly as in live.This envelope is deliberately short — it carries no
code field, despite PLAN_NOT_AVAILABLE appearing in the error-code list above.Insufficient credit — HTTP 402
Insufficient credit — HTTP 402
Live only. Sandbox reserves no credit, so this is unreachable there. Note that the field is
error_code, not code.
