Does mark_email_as_verified work with Custom Databases during initial password setup?

In the case of a change password/reset password flow, where the goal is to take advantage of the user’s first password initialization to simultaneously verify their email address, is the mark_email_as_verified feature properly applied even when a custom database is used?

Hi @MPtechteam,

Welcome to the Auth0 Community!

Yes, the mark_email_as_verified parameter is respected when using a Custom Database.

Ensure your Custom Database Login and Get User scripts return the email_verified field correctly. If your underlying legacy database doesn’t store this flag, Auth0 will rely on its own internal user profile metadata once the ticket is processed.

If you have any other questions, feel free to reach out!

Have a good one,
Vlad

1 Like

Hello Vlad,

Thank you for your response, it was very clear.

I have a follow-up question, mostly out of personal curiosity :blush:

Do you think it would be relevant for the Verify script to be executed when the mark_email_as_verified property is set to true, in order to take advantage of that step to update the Custom Database?

In my case, the email_verified field is stored in the legacy database, and the goal would be to persist this information on the Custom DB side during the verification process, rather than relying solely on Auth0’s internal user profile.

I was therefore wondering whether this behavior is something that is envisioned or recommended, or if there is a specific reason why the Verify script is not triggered in this scenario.

Thanks in advance for your insights.

Best regards,

Hi again @MPtechteam,

The behavior you are seeing stems from how Auth0 separates Identity Management (the Auth0 side) from Identity Provisioning (your legacy side).

When you use a Change Password ticket with mark_email_as_verified: true, Auth0 treats the successful password set as a “proof of ownership” for the email. Auth0 then updates its internal record of that user. However, the Verify script is architecturally decoupled from the password reset flow.

The Verify script is only invoked when the POST /api/v2/jobs/verification-email flow is used and the user interacts with that specific email verification link. Using the “Password Reset” flow to verify an email is an optimization provided by the ticket API, but it doesn’t simulate a full “Verification Email” lifecycle.

Have a good one,
Vlad

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.