Verification

Before you begin

You need an access token and your partner id. See Authentication and first request.

The X-Partner-Id header is required on every call below and is checked against the OAuth principal. A mismatch returns 403. Any channelPartnerId in a request body is ignored. It is derived from the header on the server.

Choosing a path

Three different questions, three different starting points. Pick the one that matches what you are trying to establish.

A business lookup answers two separable questions: does this company exist on ASIC, and who owns it. You can buy them apart. See choosing the depth.

To test with a company that returns people, use the ABNs and synthetic guest details in Demo test data. Screening outcomes arrive only after each guest identity check.

Confirming the structure

A request built from a KYB lookup is already authoritative and moves to READY_TO_SEND. A request you assembled yourself sits in UBO_REVIEW until you confirm it, either with structureConfirmed: true at create or afterwards:

PUT /v1/verifications/{id}/structure-confirmation

{ "confirmed": true }

You cannot mint links from UBO_REVIEW. This is the step people miss on the trust path.

Party roles

role on an individual takes any value in the VerificationRole list. It covers offices (DIRECTOR, OFFICER, SENIOR_MANAGING_OFFICIAL, AUTHORISED_REP), ownership (UBO, INDIVIDUAL_OWNER, PARTNER_MEMBER, MEMBER) and the trust roles (TRUSTEE, APPOINTOR, BENEFICIARY, SETTLOR, PROTECTOR_GUARDIAN, OTHER_CONTROLLER).

The trust roles are the same values Deed Analysis returns, so a party read off a deed can be added here unchanged. An unrecognised role is stored as OTHER rather than rejected, so send a listed value if you want it back. Use roleDescription for free text.

Verification mode

1. Create the verification request

Start with a mode; it is the only required field. Do not send firstName, lastName, email or phone. Personal information is collected from the customer through their verification link and these fields return 400 if supplied here.

POST /v1/verifications
X-Partner-Id: YOUR_PARTNER_ID
Content-Type: application/json

{ "mode": "AUSTRAC_CDD" }

The fields you can send:

Binding a FULL or UBO_ONLY lookup is the usual path:

{
  "mode": "AUSTRAC_CDD",
  "lookupRequestId": "3f0c…",
  "entityName": "Acme Pty Ltd"
}

Supply your own externalId per individual if you need one. That id, and the id Admiin returns, are how you stitch a result back to your own record. There are no names to match on.

2. Mint the verification links

POST /v1/verifications/{id}/links
X-Partner-Id: YOUR_PARTNER_ID
Content-Type: application/json

{}

An empty body mints a link for every individual on the request. Pass individualIds to mint for a subset only.

{
  "individuals": [
    {
      "id": "iv_8c21…",
      "externalId": "your-key-42",
      "verificationUrl": "https://…"
    }
  ]
}

This mints a fresh URL for every individual on the request, or for the subset you list in individualIds, and returns them in the response body. Status moves from DRAFT to VERIFICATIONS_SENT.

Capture the URLs from this response. They are returned here and nowhere else: never by webhook, never by GET /v1/verifications/{id}, and never in a queryable form. Only an HMAC-SHA-256 digest of the token is stored at rest.

3. Read the result

Terminal individual webhooks tell you when a person finishes: verification.individual.passed, failed or manual_review. See Webhooks for signature validation and retries.

GET /v1/verifications/{id}
X-Partner-Id: YOUR_PARTNER_ID

Use this to confirm terminal status after the webhook fan-out has run, or to poll if your receiver is briefly offline. It returns the itemised outcome for every individual on the request.

A lookup-bound response includes lookupRequestId on create, get and list. Join each verification individual back to the business lookup ownership graph by idvEntityId. The lookup proves that the register identified the party; only a later individual status of PASSED or MANUALLY_PASSED means the identity was verified.

Rendering the result panel

GET /v1/verifications/{id} returns the data needed to present verification results. How you display it is up to your application.

Treat checkResults[].checkType, result and code as provider-defined strings and handle unknown values. Request and individual status values are the closed enums defined in the API reference.

Fetching evidence

The deep evidence behind a result is not in webhooks. Poll for it after you receive a terminal individual webhook. Two endpoints return it for an individual you own:

GET /v1/verifications/{id}/individuals/{individualId}/document-details
GET /v1/verifications/{id}/individuals/{individualId}/aml-matches

document-details returns the uploaded ID documents, OCR-extracted fields, the applicant's claimed identity and the biometric selfie comparison. Images are included by default; pass ?includeScans=false for OCR and metadata only.

aml-matches returns the matched-entity detail behind a PEP, sanction, watchlist or adverse-media hit, plus KYC fraud-check matches, in a single round-trip.

Both live-fetch from the screening service on each call and persist nothing. Both always return 200 with a status discriminator rather than a hard error, so branch on status:

When a screening hit needs a decision recorded against it, see Reviewing AML matches.

For branded PDF records, see Verification reports.

When the address does not match

Some people fail identity matching only because their current address is too new to appear in the sources checked. The hosted verification page can collect a previous address as part of the first check. The separate partner API is enabled by arrangement.

Supplying a previous address

A previous address from the last 12 months can fix the match. There is a hosted collection step. A separate partner API can also accept an address when that capability is enabled for your organisation.

In the verification page. The hosted page asks the person whether they have lived at their current address for less than 12 months. If they have, it collects the previous address and includes it in their one verification submission. Admiin records only their answer and the notice they were shown, never the address.

Through the API. If you already hold the previous address, attach it yourself:

POST /v1/verifications/{id}/individuals/{individualId}/previous-address

The address is passed to our verification provider for matching and is not stored by Admiin. Send "recheck": true to re-run the check with it. A re-check is charged like a new submission, runs in the background and is allowed once per address while the person's status is FAILED. The result arrives through your usual individual webhooks.

Manual identity review

For an AUSTRAC_CDD person whose identity document passed but whose address match failed, your trained reviewer can complete a manual identity review and record it:

POST /v1/verifications/{id}/individuals/{individualId}/manual-kyc

Send the documents you relied on, with scans: one primary photographic document, two primary non-photographic documents or one primary non-photographic document with one secondary document. Give issuer as a short upper-case code such as NSW, never a document number or a name. Scans and full document numbers are not stored by Admiin.

A clear politically exposed person and sanctions screen is required. If one has already run it is reused at no charge. Otherwise one runs at submission and is charged once, as KYC_PEP_SANCTIONS. A potential match refuses the manual pass.

A recorded review means identity evidence was accepted on reasonable grounds. It does not decide whether you may provide your designated service. This route is off until enabled for your organisation.

Personal information

Evidence responses contain personal information, including document images, OCR fields and AML matched-entity detail.

Handle and store them in line with your own privacy policy, your data-handling obligations and the partner agreement.