0D5WR000028rI4R0AUOkta Classic EngineUniversal DirectoryAnswered2026-09-17T19:05:49.000Z2026-09-16T11:15:05.000Z2026-09-17T19:05:49.000Z

NoelR.00312 (Customer) asked a question.

September 16, 2026 at 11:15 AM

Okta User Status Transition Event Hooks - Pending Activation -> Active

Hi,

 

Working on syncing user status between two systems, using event hooks at the moment to be made aware of any user status transitions (activation, deactivation, deletion, profile updates) initiated from Okta.

 

Running into an problem that I can't seem to find any answer to apart from working around this limitation, is there an Event that my API could listen for, to identify a user transitioning from Pending Activation to Active?

 

The only answers I've found so far is looking for the below on a 'user.account.update_password' event, which is not ideal for our use case, where we have an approval process in between creation and activation of a user, and the requirement to accurately display where a user is still awaiting activation.

 

event.data.events[0].debugContext.debugData.requestUri === "/user/welcome/login/internal"

 

Is there a better documented way to identify this transition? If not, are there any plans to make a mechanism available for this?

 

Thanks in advance.

  • 3 answers
  • 37 views

  • Paul S. (Okta, Inc.)

    Hello @NoelR.00312 (Customer)​ If you are using a magic link or a passwordless flow, user.account.update_password won't work because the user might never actually set a password. Since user.lifecycle.activate only confirms the API call was made to send the email, you need an event that proves the user completed the flow and successfully accessed the account.

    Here are the two best events to rely on to prove the user has reached a working state.

    1. The "First Session" Strategy (Recommended)

    The most definitive proof that a user has successfully onboarded is that they established a session. When a user clicks an Okta magic link and completes any required onboarding steps, Okta immediately logs them in and drops a session token.

    Instead of looking for a password or lifecycle change, configure your event hook to listen for user.session.start.

    1. The Logic: When your API receives the user.session.start event, extract the userId and check it against your local database.
    2. The Transition: If your local system shows that user is currently in a "Pending" state, this first user.session.start event is your definitive trigger that they have successfully accepted the link, completed any required setup, and are fully active. You can then update their status to "Active" in your system.

    Okta Identity Engine (OIE) Note: In OIE, clicking the magic link itself registers as an authentication event (user.authentication.auth_via_email). However, user.session.start remains the safest indicator that the user completed the entire onboarding process, rather than just clicking the link and abandoning a subsequent setup step.

    2. The Authenticator Enrollment Strategy

    If your onboarding process specifically requires the user to set up a secondary factor (like Okta Verify, SMS, or a Security Question) immediately after clicking the magic link, you can track the completion of that setup instead.

    Configure your event hook to listen for user.mfa.factor.activate

    (oruser.authentication.enroll, depending on your specific Okta configuration).

    1. The Logic: This event fires the exact moment a user successfully binds an authenticator to their account.
    2. The Transition: Similar to the session strategy, if the user is currently "Pending" in your system and you receive this event, it confirms they are actively successfully navigating the onboarding flow and their account is now in a working state.

     

    Expand Post
    Selected as Best

  • Paul S. (Okta, Inc.)

    Hello @NoelR.00312 (Customer)​  Thank you for posting on our Community page!

     

    You are asking whether Okta Event Hooks provide a dedicated event to detect when a user transitions from Pending Activation status to Active status, particularly for scenarios where an approval process occurs between user creation and activation.

    The user.lifecycle.activate event is the standard Event Hook event that fires when a user is activated in Okta. This event should trigger whenever a user moves to Active status, regardless of the previous state. However, the event payload itself does not explicitly distinguish between different prior states (such as Staged or Pending Activation), so you would need to query the user's current status or check the event context to confirm the transition occurred.

    Root Cause: Event Hooks in Okta fire based on the action that occurs (activation, deactivation, etc.) rather than on specific state transitions. The user.lifecycle.activate

    event fires when the activate action is performed, but the event data does not inherently include the previous user state, making it difficult to confirm a transition from Pending Activation specifically without additional logic.

    Solution: Use the user.lifecycle.activate

    event as your primary listener, and supplement it with user status verification:

    1. Configure your Event Hook to listen for the user.lifecycle.activate event type in the Okta Admin Console or via the Event Hooks API.
    2. In your event handler, when you receive a user.lifecycle.activate event, query the Okta Users API to retrieve the current user object and confirm the user's status is now ACTIVE.
    3. Log or process the activation in your downstream system once you have confirmed the status change. This approach works regardless of the user's previous state.
    4. Alternatively, if you need to distinguish activation sources, examine the event payload's debugContext or actor fields to understand whether the activation was triggered by an admin action, a user self-service action, or an automated workflow. This may help you filter for the specific approval-driven activations your process requires.

    The workaround you mentioned (checking requestUri === "/user/welcome/login/internal"

    on user.account.update_password events) is a community-discovered pattern but is not an officially documented or recommended approach. The user.lifecycle.activate

    event is the supported mechanism for detecting user activation.

    Note on Event Hook Timing: Event Hooks may have a slight delay before they are ready to receive events after creation. If you recently set up your hook, allow approximately 60 seconds before testing.

    For comprehensive details on available Event Hook event types and their payloads, see the Okta Event Hooks documentation and the Users API lifecycle operations reference.

    We hope this resolves your question. If you need account-specific guidance on your approval workflow integration, please contact Okta Support for further assistance.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post

  • NoelR.00312 (Customer)

    Hi @Paul S. (Okta, Inc.)​,

     

    Thanks for getting back to me.

     

    This would be great, although I'm specifically interested in understanding when a user has accepted the magic link, or has actually 'on boarded' their account into a working state. This event appears to fire immediately after the lifecycle API call to activate the user (with sendEmail=true) is made, at which point it's a little bit redundant for this specific scenario.

     

    Thanks for the information regardless, hope I'm explaining this correctly!

    Expand Post

    • Paul S. (Okta, Inc.)

      Hello @NoelR.00312 (Customer)​ If you are using a magic link or a passwordless flow, user.account.update_password won't work because the user might never actually set a password. Since user.lifecycle.activate only confirms the API call was made to send the email, you need an event that proves the user completed the flow and successfully accessed the account.

      Here are the two best events to rely on to prove the user has reached a working state.

      1. The "First Session" Strategy (Recommended)

      The most definitive proof that a user has successfully onboarded is that they established a session. When a user clicks an Okta magic link and completes any required onboarding steps, Okta immediately logs them in and drops a session token.

      Instead of looking for a password or lifecycle change, configure your event hook to listen for user.session.start.

      1. The Logic: When your API receives the user.session.start event, extract the userId and check it against your local database.
      2. The Transition: If your local system shows that user is currently in a "Pending" state, this first user.session.start event is your definitive trigger that they have successfully accepted the link, completed any required setup, and are fully active. You can then update their status to "Active" in your system.

      Okta Identity Engine (OIE) Note: In OIE, clicking the magic link itself registers as an authentication event (user.authentication.auth_via_email). However, user.session.start remains the safest indicator that the user completed the entire onboarding process, rather than just clicking the link and abandoning a subsequent setup step.

      2. The Authenticator Enrollment Strategy

      If your onboarding process specifically requires the user to set up a secondary factor (like Okta Verify, SMS, or a Security Question) immediately after clicking the magic link, you can track the completion of that setup instead.

      Configure your event hook to listen for user.mfa.factor.activate

      (oruser.authentication.enroll, depending on your specific Okta configuration).

      1. The Logic: This event fires the exact moment a user successfully binds an authenticator to their account.
      2. The Transition: Similar to the session strategy, if the user is currently "Pending" in your system and you receive this event, it confirms they are actively successfully navigating the onboarding flow and their account is now in a working state.

       

      Expand Post
      Selected as Best

Recommended content

No recommended content found...