> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.id.me/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.id.me/_mcp/server. # Event patterns > The order in which user verification events are emitted for common verification journeys. Which user verification events are emitted, and in what order, depends on the path the user takes through IDMe. A user who uploads their ID from a desktop emits different events from one who continues on their phone, and a user who is already verified emits far fewer events than a new user. This page shows the events for the most common journeys, so you know what to expect and can spot when an event is missing. See [User verification events](/shared-signals-framework/user-verification-events) for the delivery envelope, the fields every event carries, and the full list of event types. > **Note** > > Each pattern lists the events emitted for that journey. You only receive the events your Audience is subscribed to, and events for a user who has not yet consented are embargoed until consent is granted. See [Process](/shared-signals-framework/user-verification-events#process). # Before verification Every journey starts with the user signing up or signing in. These events come before the verification events in each pattern below: 1. [`session.signup`](/shared-signals-framework/user-verification-events#event-types) for a new user, or [`session.signin`](/shared-signals-framework/user-verification-events#event-types) for a returning user 2. [`session.verification_status`](/shared-signals-framework/user-verification-events#event-types) 3. The `email.confirmation.*` events, for a new user confirming their email 4. The `2fa.*` events, as the user sets up or completes multifactor authentication # Pre-verified users ## Already verified The user already holds the identity level your policy requires. They sign in and return to your application without verifying again, so no verification events are emitted. 1. [`session.signin`](/shared-signals-framework/user-verification-events#event-types) 2. [`session.verification_status`](/shared-signals-framework/user-verification-events#event-types) 3. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types), only the first time the user shares their information with your application 4. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types) ## Re-running liveness The user is already verified but is asked to confirm it's them with a new liveness check, which they complete on their phone. 1. [`verification.transition.liveness.live_selfie_option`](/shared-signals-framework/user-verification-events#event-types) 2. [`verification.transition.selfie.text_phone_live_selfie`](/shared-signals-framework/user-verification-events#event-types) 3. [`verification.transition.liveness.phone_liveness`](/shared-signals-framework/user-verification-events#event-types) 4. [`verification.transition.liveness.liveness_ready`](/shared-signals-framework/user-verification-events#event-types) 5. [`verification.complete`](/shared-signals-framework/user-verification-events#event-types) 6. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types) 7. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types) A user re-running liveness does not repeat the document, phone, or personal information steps, so none of those events are emitted. # New users ## Happy path: continue on phone The user chooses to continue on their phone, captures their ID and completes a liveness check there, and passes every check on the first try. This is the default path for a new user. 1. [`verification.transition.documents.text_phone`](/shared-signals-framework/user-verification-events#event-types): the user chooses to continue on their phone 2. [`verification.transition.documents.polling_documents`](/shared-signals-framework/user-verification-events#event-types): waiting for the photos from the phone 3. [`verification.transition.liveness.phone_liveness`](/shared-signals-framework/user-verification-events#event-types): document accepted, liveness check on the phone 4. [`verification.transition.liveness.liveness_ready`](/shared-signals-framework/user-verification-events#event-types) 5. [`verification.transition.authoritative_records.social_info`](/shared-signals-framework/user-verification-events#event-types): Social Security number entry 6. [`verification.transition.authoritative_records.review_info`](/shared-signals-framework/user-verification-events#event-types): the user reviews the information read from their ID 7. [`verification.transition.telecom.utility_verify`](/shared-signals-framework/user-verification-events#event-types): phone check 8. [`verification.transition.authoritative_records.verify_name`](/shared-signals-framework/user-verification-events#event-types) 9. [`verification.complete`](/shared-signals-framework/user-verification-events#event-types) 10. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types) 11. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types) Because the user continued on their phone, the phone they used is already confirmed, so no `telecom.phone_info` step is shown. ## Upload on desktop The user doesn't continue on their phone. They capture their ID and complete a liveness check with their computer's webcam. 1. [`verification.transition.documents.text_phone`](/shared-signals-framework/user-verification-events#event-types): the user is offered to continue on their phone 2. [`verification.transition.documents.document_review`](/shared-signals-framework/user-verification-events#event-types): the user chooses to continue on the computer and captures their ID 3. [`verification.transition.documents.document_verify`](/shared-signals-framework/user-verification-events#event-types) 4. [`verification.transition.selfie.selfie_option`](/shared-signals-framework/user-verification-events#event-types) 5. [`verification.transition.liveness.webcam_liveness`](/shared-signals-framework/user-verification-events#event-types) 6. [`verification.transition.liveness.liveness_ready`](/shared-signals-framework/user-verification-events#event-types) 7. [`verification.transition.telecom.phone_info`](/shared-signals-framework/user-verification-events#event-types): phone number entry 8. [`verification.transition.authoritative_records.social_info`](/shared-signals-framework/user-verification-events#event-types) 9. [`verification.transition.authoritative_records.review_info`](/shared-signals-framework/user-verification-events#event-types) 10. [`verification.transition.telecom.utility_verify`](/shared-signals-framework/user-verification-events#event-types) 11. [`verification.transition.authoritative_records.verify_name`](/shared-signals-framework/user-verification-events#event-types) 12. [`verification.complete`](/shared-signals-framework/user-verification-events#event-types) 13. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types) 14. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types) ## Variations Small differences in the path change which events you receive: | If the user… | You receive | | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Uploads image files of their ID instead of using the camera | [`verification.transition.documents.upload_file`](/shared-signals-framework/user-verification-events#event-types) | | Has the IDMe mobile app and is sent to it | [`verification.transition.documents.app_links`](/shared-signals-framework/user-verification-events#event-types) and [`verification.transition.documents.awaiting_mobile`](/shared-signals-framework/user-verification-events#event-types) instead of `documents.text_phone` | | Needs to enter personal information that couldn't be read from their ID | [`verification.transition.authoritative_records.personal_info`](/shared-signals-framework/user-verification-events#event-types) | | Needs to enter their address | [`verification.transition.authoritative_records.address_info`](/shared-signals-framework/user-verification-events#event-types) | # Fail to supervised path ## After an unsupervised failure The user can't complete self-service verification, for example because their document can't be verified, and is offered a video call with an IDMe agent instead. 1. The verification events up to the step that failed, as in [New users](#new-users) 2. A failure event, such as [`verification.transition.documents.failed_document`](/shared-signals-framework/user-verification-events#event-types) 3. [`appointment.start`](/shared-signals-framework/user-verification-events#event-types): the user chooses to verify on a video call 4. The `supervised.appointments.*` events, if the user schedules an appointment 5. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types): after the agent approves the verification 6. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types) The failure event depends on the step that failed: | Step | Failure events | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Document | [`verification.transition.documents.failed_document`](/shared-signals-framework/user-verification-events#event-types), [`verification.transition.documents.failed_doc_review`](/shared-signals-framework/user-verification-events#event-types), [`verification.transition.documents.failed_document_data`](/shared-signals-framework/user-verification-events#event-types), [`verification.transition.documents.reached_upload_limit`](/shared-signals-framework/user-verification-events#event-types) | | Phone | [`verification.transition.telecom.failed_phone_verification`](/shared-signals-framework/user-verification-events#event-types), [`verification.transition.telecom.failed_utility`](/shared-signals-framework/user-verification-events#event-types), [`verification.transition.telecom.failed_single_source`](/shared-signals-framework/user-verification-events#event-types) | > **Note** > > `verification.complete` is not emitted when an agent completes the verification on a video call. Use `consent.allow` and `transaction.complete` to tell that the user finished. ## Choosing a video call The user chooses to verify on a video call from the verification options screen, instead of starting self-service verification. 1. [`verification.options`](/shared-signals-framework/user-verification-events#event-types) 2. [`verification.choice.dtr_full`](/shared-signals-framework/user-verification-events#event-types) 3. [`appointment.start`](/shared-signals-framework/user-verification-events#event-types) 4. The `supervised.appointments.*` events, if the user schedules an appointment 5. [`consent.allow`](/shared-signals-framework/user-verification-events#event-types) 6. [`transaction.complete`](/shared-signals-framework/user-verification-events#event-types)