Skip to main content

Overview

The Form module consists of 13 screens that guide users through the verification flow. Each screen emits events following a consistent naming pattern.

Event Naming Convention

All screen events follow the pattern:
For example: form:welcome:ready, form:review:success, form:result:pending

Event Stages

Event Payload

All screen events emit an EventPayload object:

Screen Reference

All examples below assume the SDK has been initialized:

Welcome

The first screen shown to users. Introduces the verification process and provides a call-to-action to begin. Screen ID: welcome Events: Example:

Start

Entry point screen for certain flows. Allows configuration of the initial verification step. Screen ID: start Events:
Collects user consent for identity verification and data processing. Screen ID: consent Events: Example:

Document Selection

Allows users to select which identity document(s) they want to use for verification (e.g., driver’s licence, passport, national ID, Medicare card). Used in manual and doc_upload flows.
In OCR mode, the Document Selection screen is a legacy feature tied to headless OCR flows. Modern integrations use the IDV flow for document capture and the form Review screen to display extracted data.
Screen ID: document Supported Document Types:
  • DRIVERS_LICENCE - Driver’s licence
  • PASSPORT - Passport
  • NATIONAL_ID - National identity card
  • NATIONAL_HEALTH_ID - National health ID / Medicare card
Events: Example:

Personal Details

Collects personal information such as name, date of birth, and address. Screen ID: personal Events: Example:

Review

Displays collected data for user review before submission. In manual mode with verify: true, submits the data for verification and navigates to the appropriate result screen automatically. When customResult: true is also set, the form emits review-level result events instead of navigating to result screens, giving you full control over result handling. Screen ID: review Events:
form:review:failed/success/partial/pending require customResult: true in manual mode.These four events are only emitted when customResult: true is set on the review component in manual mode. When customResult is false (the default), the form automatically navigates to the configured result screen — these review-level result events are not emitted. In OCR mode, the only review event is form:review:ready.See verify and customResult in the configuration reference.
Example (with customResult: true):

Loading

Displayed while verification is being processed. Screen ID: loading This screen is managed internally by the form module and typically does not require event handling.

Result

Displays the final verification result to the user. Shows success, failure, partial match, or pending status. Screen ID: result Result States: Events: Example:

Retry

Shown when verification returns a partial result and the user can retry. Allows re-entry of data that failed verification and intelligently adapts the retry flow based on the type of failure. Screen ID: retry Events: Example:

Smart Retry Behavior

The Retry screen intelligently adapts based on the type of verification failure. When verification returns a partial match, the SDK analyzes the failure type and presents the appropriate retry flow.
Triggered when: Verification returns a partial alert on personal details (e.g., address could not be confirmed against records).What happens: The Retry screen displays the personal details form with an additional toggle asking “Have you been at your current residential address for less than 6 months?” When the user enables this toggle, a previous address field appears prompting them to enter their prior residential address.Purpose: Helps resolve address verification failures by providing additional residential history that the verification provider can use to confirm the user’s identity.
Triggered when: Primary ID verification fails with a 404 alert (e.g., the submitted document could not be verified against records).What happens: The Retry screen displays additional document types that have not been submitted yet, prompting the user to select and fill in an alternative form of ID. Documents already submitted are filtered out from the selection list.Purpose: Provides a fallback path when the initial document cannot be verified, allowing the user to supply a different identity document for verification.
Retry Flow:
  1. Initial verification is submitted from the Review screen
  2. Verification returns a partial result (via partial or 404 alert)
  3. The SDK determines the failure type: personal details failure (VERIFICATION_FAILED_IDS.NAME) or document failure (VERIFICATION_FAILED_IDS.ID)
  4. The Retry screen presents the appropriate fields based on the failure type
  5. The user provides additional information (previous address or alternative ID)
  6. The flow transitions to the Review screen for re-submission
Example with retry limit:

Document Upload

Main document upload screen for uploading supporting documents. Screen ID: doc_upload Events: Example:

Required Document Upload

Displays documents that are required for verification and must be uploaded. Screen ID: required_document_upload Events:

Partial Document Upload

Displays a list of documents where a minimum number must be uploaded (e.g., “upload at least 2 of these 4 documents”). Screen ID: partial_document_upload Events:

Optional Document Upload

Displays optional documents that users can upload to strengthen their verification. Screen ID: optional_document_upload Events:

Typical Screen Flow

OCR Flow (with IDV)

The IDV flow handles document capture. The form module provides the Review screen to display extracted data for user confirmation.

Manual Flow

Document Upload Flow


Screen-Level Event Listening Example