Skip to navigation
Real Time EventsUser Verification Events

Event patterns

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 for the delivery envelope, the fields every event carries, and the full list of event types.

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.

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 for a new user, or session.signin for a returning user
  2. session.verification_status
  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
  2. session.verification_status
  3. consent.allow, only the first time the user shares their information with your application
  4. transaction.complete

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
  2. verification.transition.selfie.text_phone_live_selfie
  3. verification.transition.liveness.phone_liveness
  4. verification.transition.liveness.liveness_ready
  5. verification.complete
  6. consent.allow
  7. transaction.complete

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: the user chooses to continue on their phone
  2. verification.transition.documents.polling_documents: waiting for the photos from the phone
  3. verification.transition.liveness.phone_liveness: document accepted, liveness check on the phone
  4. verification.transition.liveness.liveness_ready
  5. verification.transition.authoritative_records.social_info: Social Security number entry
  6. verification.transition.authoritative_records.review_info: the user reviews the information read from their ID
  7. verification.transition.telecom.utility_verify: phone check
  8. verification.transition.authoritative_records.verify_name
  9. verification.complete
  10. consent.allow
  11. transaction.complete

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: the user is offered to continue on their phone
  2. verification.transition.documents.document_review: the user chooses to continue on the computer and captures their ID
  3. verification.transition.documents.document_verify
  4. verification.transition.selfie.selfie_option
  5. verification.transition.liveness.webcam_liveness
  6. verification.transition.liveness.liveness_ready
  7. verification.transition.telecom.phone_info: phone number entry
  8. verification.transition.authoritative_records.social_info
  9. verification.transition.authoritative_records.review_info
  10. verification.transition.telecom.utility_verify
  11. verification.transition.authoritative_records.verify_name
  12. verification.complete
  13. consent.allow
  14. transaction.complete

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 cameraverification.transition.documents.upload_file
Has the IDMe mobile app and is sent to itverification.transition.documents.app_links and verification.transition.documents.awaiting_mobile instead of documents.text_phone
Needs to enter personal information that couldn’t be read from their IDverification.transition.authoritative_records.personal_info
Needs to enter their addressverification.transition.authoritative_records.address_info

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
  2. A failure event, such as verification.transition.documents.failed_document
  3. appointment.start: the user chooses to verify on a video call
  4. The supervised.appointments.* events, if the user schedules an appointment
  5. consent.allow: after the agent approves the verification
  6. transaction.complete

The failure event depends on the step that failed:

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
  2. verification.choice.dtr_full
  3. appointment.start
  4. The supervised.appointments.* events, if the user schedules an appointment
  5. consent.allow
  6. transaction.complete