Look up an individual on the Australian Immunisation Register (AIR), match by Medicare card, IHI, and personal details, and receive their AIR record together with an opaque individualIdentifier for use in subsequent history and update calls.
For shared response patterns and the full status-code list, see AIR Integration.
On a successful match, AIR returns individualDetails.individualIdentifier — an opaque, encrypted token unique to the individual.
Treat individualIdentifier as opaque. Don’t display it to end users, log it in customer-facing analytics, or store it anywhere that might leak. Reuse it on every subsequent AIR call for the same individual (history, exemption, indicator updates).
Identifiers are not portable across providers — each information provider gets a different token for the same individual.
AIR matches against four field combinations, evaluated in order. The first one that uniquely identifies an individual wins; remaining fields are ignored.
Scenario 4 covers individuals with only one name (no firstName). Submitting too little returns AIR-E-1026 (insufficient information).
Recommended: send Scenario 1 or Scenario 3 — Medicare card or IHI alongside personal details gives the best match.
Date fields use DDMMYYYY with no separators (e.g. 18042016).
AIR returns individualDetails.endDateCode when the individual has restrictions on their record.
Don’t display endDateCode to end users — it’s an internal AIR signal. Use it to drive UI state (read-only, partial-update, full-access) but show the human-readable consequence to the user, not the code itself.
Top-level outcomes for this endpoint:
Identification details. See the Minimum identification requirements table in the operation description for valid combinations.
AIR status code. See Status codes.
Code-type category.
Present on a successful match (AIR-I-1100) and on the end-date warnings (AIR-W-1059, AIR-W-1062). null on validation errors and AIR-E-1058.