Self-Hosted: Email Verify Redirect Problem
Hello! I’m using self-hosted ZITADEL and creating users with the /v2/users API with isVerified = false. I have an HTTP Email Provider configured, and the user receives the email verification / password initialization email correctly.
The issue is the redirect after password setup:
When the user follows the email verification link, they end up on the ZITADEL Console instead of my app.
But when using Forgot / Reset Password, after password change the user is redirected to my web app correctly.
I already have my frontend URL configured in the Application Redirect URIs and under Project → Application → Redirect URI.
So password reset flow = correct redirect
Email verify = always redirects to ZITADEL Console
I noticed the reset password URL includes authRequestID, so it returns to my app as expected — but the verify/init password email link does not include authRequestID, so the redirect falls back to the console UI.
Question:
Is there a separate redirect config for the initial password set / email verification flow, or am I missing something in the recommended Create → Verify → Login flow or any way to trigger the authRequestID flow during the initial password setup / verification process so that users are redirected back to my application instead of the console?
Any guidance on the recommended flow would be greatly appreciated, Thank you.
1 Reply
Hi @Sherin, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.
Answer
---
The redirect behavior you're experiencing is expected. When the user clicks the email verification link without an active authorization request (authRequestID) , ZITADEL uses the Default Redirect URI configured in your login behavior settings (1) .
The password reset flow works correctly because it's initiated during an active login session with an authRequestID, which maintains the context of your application . The email verification link, however, is sent outside of any authorization flow, so there's no authRequestID to preserve the redirect context .
Solution: Configure Default Redirect URI
You can configure the default redirect URL in the login behavior settings, which is used when there is no authRequestID . This setting is available at both the instance level and organization level .
To set this up:
1. Navigate to your instance or organization settings
2. Find the login behavior/default settings section
3. Set the Default Redirect URI to your application URL (e.g., `https://example.com/me%60)
After successful login following the email verification link, the user should be redirected to your configured default redirect URI .
Alternative Approach
If you need more control over the initial password setup flow, consider initiating the user creation flow from within your application's authorization request. This way, the authRequestID context is maintained throughout the entire process, and users will be redirected back to your application automatically after completing email verification and password setup (2) .
To learn more, see the sources I considered:
[1] In which situations is the "Default Redirect URI" used?
[2] Authenticate users with OpenID Connect
Feel free to tag @Ask Inkeep with additional questions.
Glad I could be helpful. Feel free to create a new thread with any new questions you may have.