Verifies input data against the Document Verification Service (DVS). Didit exposes this service through `POST /v3/database-validation/` so you can verify the submitted data against the authoritative source and receive normalized match results. ## Coverage * **Coverage:** 100%\* * **Country:** Australia * **Service ID:** `aus_immicard` * **Data domain:** Document * **Category:** Visa ## Inputs | Field | Required | Example | | ----------------------- | -------: | ------------------- | | `first_name` | Yes | `John` | | `last_name` | Yes | `Doe` | | `date_of_birth` | Yes | `1990-01-01` | | `immi_card_number` | Yes | `SAMPLE-IMMI-12345` | | `immi_card_expiry_date` | Yes | `2030-01-01` | | `vendor_data` | No | `user-1234` | * **Required inputs:** `first_name`, `last_name`, `date_of_birth`, `immi_card_number`, `immi_card_expiry_date` * **Optional inputs:** `vendor_data` * **Consent:** Required * **Workflow availability:** Available in workflow * **Coverage:** 100%\* * **Price:** \$0.45 per successful query ## Body parameters ISO 3166-1 alpha-3 country code for this database service. Example: `AUS` Array containing this service ID. Pinning the service keeps the request scoped to this exact database. Example: `aus_immicard` Explicit end-user consent for this service. Example: `true` Given name to validate. Example: `John` Family name to validate. Example: `Doe` Date of birth in `YYYY-MM-DD` format. Example: `1990-01-01` `immi_card_number` value required by this database service. Example: `SAMPLE-IMMI-12345` `immi_card_expiry_date` value required by this database service. Example: `2030-01-01` Your stable user reference for this person, such as your internal user ID. Didit uses it to link standalone checks to the same end user and reduce duplicate-detection noise. Example: `user-1234` ## Input rules & validation notes * Send the fields listed above exactly as captured from the user or document. * Didit validates required fields before calling the database. Requests rejected before source lookup are not charged. ## How to call it ```bash cURL theme={null} curl -X POST "https://verification.didit.me/v3/database-validation/" \ -H "x-api-key: YOUR_API_KEY" \ -F "issuing_state=AUS" \ -F "services=aus_immicard" \ -F "vendor_data=user-1234" \ -F "consent=true" \ -F "first_name=John" \ -F "last_name=Doe" \ -F "date_of_birth=1990-01-01" \ -F "immi_card_number=SAMPLE-IMMI-12345" \ -F "immi_card_expiry_date=2030-01-01" ``` Every successful call returns HTTP `200`. The **`outcome_code`** field tells you what actually happened — distinguishing, for example, a real biometric mismatch (`BIOMETRIC_NO_MATCH`) from a selfie that could not be read (`BIOMETRIC_IMAGE_UNUSABLE`). The `status` shown is the default feature status; your configured [Partial Match / No Match actions](/core-technology/database-validation/database-validation-warnings) can override it. **`MATCH`** — The registry confirmed the identity and every checked field matched. ```json 200 OK — MATCH theme={null} { "request_id": "req_01H…", "status": "Approved", "issuing_state": "AUS", "match_type": "full_match", "validations": [ { "outcome_code": "MATCH", "service_id": "aus_immicard", "service_name": "Australia - DVS - ImmiCard", "source_data": { "date_of_birth": "1990-01-01", "first_name": "John", "identification_number": "SAMPLE-ID-12345", "last_name": "Doe" }, "validation": { "date_of_birth": "full_match", "full_name": "full_match", "identification_number": "full_match" } } ] } ``` **`PARTIAL_MATCH`** — The identification number was found but one or more personal fields (usually name or date of birth) did not fully match. ```json 200 OK — PARTIAL_MATCH theme={null} { "request_id": "req_01H…", "status": "In Review", "issuing_state": "AUS", "match_type": "partial_match", "validations": [ { "outcome_code": "PARTIAL_MATCH", "service_id": "aus_immicard", "service_name": "Australia - DVS - ImmiCard", "source_data": { "date_of_birth": "1990-01-01", "first_name": "John", "identification_number": "SAMPLE-ID-12345", "last_name": "Doe" }, "validation": { "date_of_birth": "full_match", "full_name": "no_match", "identification_number": "full_match" } } ] } ``` **`NO_MATCH`** — The registry returned no match for the submitted data. ```json 200 OK — NO_MATCH theme={null} { "request_id": "req_01H…", "status": "Declined", "issuing_state": "AUS", "match_type": "no_match", "validations": [ { "outcome_code": "NO_MATCH", "service_id": "aus_immicard", "service_name": "Australia - DVS - ImmiCard", "source_data": { "date_of_birth": "NO_MATCH", "full_name": "NO_MATCH", "identification_number": "NO_MATCH" }, "validation": { "date_of_birth": "no_match", "full_name": "no_match", "identification_number": "no_match" } } ] } ``` ## Returned data The exact fields surfaced in `source_data` depend on what the registry returns. The generated example for `aus_immicard` currently documents this normalized shape: * `date_of_birth` * `first_name` * `identification_number` * `last_name` ## Pricing & SLAs Australia - DVS - ImmiCard queries are billed only when Didit receives a conclusive result from the validation source. * **Per-call price:** \$0.45 USD. * **Billing:** per successful query. You are not charged when the registry is unreachable, when required fields are missing, or when the request is rejected before reaching the source. * **Latency:** typical p95 \< 2 s. * **Availability:** 99.9% per quarter on Didit's side; downstream source availability varies by country and dataset. ## Continue reading * [Australia Database Validation overview](/api-reference/database-validation/australia) * [Database Validation overview](/core-technology/database-validation/overview) * [Outcome Codes](/core-technology/database-validation/database-validation-outcome-codes)