Account lookup
Choose the recovery identifier deliberately, usually email or username.
Password Reset: Request and Token Flow
Plan the first half of a Wappler password-reset flow: request handling, token generation, and safe handoff into reset links.
Introduction
Section titled “Introduction”This tour explains the first half of password reset as a trusted recovery workflow, not just a form that emails a link. In Wappler, the request step decides how accounts are looked up, how reset tokens are created, and how much information the app should reveal when someone asks to recover access.
Password reset starts with account recovery policy
Section titled “Password reset starts with account recovery policy”The reset-request step decides who can ask for recovery, what data identifies the account, how the token is created, and what response the user sees. A solid reset flow protects privacy while still helping legitimate users regain access.
Reset token
Generate a temporary recovery link or code with a clear lifetime.
Neutral response
Avoid leaking whether an account exists when that matters for security.
Design recovery around a trusted identifier
Issue reset tokens with a clear expiry model
Keep the visible response safe and predictable
The email is part of the security flow
Section titled “The email is part of the security flow”The reset message is not just a notification. It is the handoff into the second half of the recovery path. That means the token, expiry rule, and destination route all need to line up cleanly before the app sends anything.
Treat the email link as part of the auth flow
Keep the reset destination route explicit
Test expired and invalid token paths early
Common reset-request patterns
Section titled “Common reset-request patterns”Most password reset flows in Wappler reduce to a few design choices.
Pattern: create a short-lived reset token
Section titled “Pattern: create a short-lived reset token”The recovery token should be specific enough to identify the reset attempt and short-lived enough that old links do not remain useful. The app should know exactly where that token will be consumed later.
important: Reset tokens should be temporary and should only lead into a purpose-built reset route.
Keep token lifetime finite
Send users to one explicit reset destination
Plan invalid and expired token handling up front
Pattern: use a predictable user-facing response
Section titled “Pattern: use a predictable user-facing response”Even when the account lookup fails or is ambiguous, the response shown to the user should still feel consistent. That keeps recovery understandable without revealing more than necessary about valid accounts.
Keep the confirmation message stable
Separate user guidance from account enumeration risk
Make the next expected action obvious
Related account-recovery steps
Section titled “Related account-recovery steps”The request flow only works when the follow-up reset page and new-password storage path are designed at the same time.
Wrap-up
Section titled “Wrap-up”Continue into the reset-completion or broader security branch from here.
Next steps
Section titled “Next steps”Pick the next recovery topic to continue with.