Troubleshooting login and access
Use this article when a customer cannot sign in, gets redirected unexpectedly, cannot accept an invite, or sees a page that says access is missing.
When to use this
Use this article when someone says:
They are stuck on the login page.
They were sent to login after opening a protected page.
They forgot their password.
They clicked an email confirmation or password reset link and nothing happened.
They opened an invite link but are signed in with the wrong email.
They were told their invite is invalid or expired.
Step-by-step
Use this article when a customer cannot sign in, gets redirected unexpectedly, cannot accept an invite, or sees a page that says access is missing.
LenGrowth uses a small set of auth routes for these situations:
/invites/[token]
The login system preserves the route the user was trying to reach and sends them back after sign-in when possible. That means a redirect to login is often not the end of the journey. It is usually just a sign that the session needs to be restored first.
The login page can also show a reauthentication banner when LenGrowth needs the session restored. That message is not the same thing as a bad password. It means the app wants you to sign in again so it can continue loading protected pages.
The callback flow is worth understanding because it handles more than one auth event. The same route can finish a normal sign-in, confirm an email signup, verify a magic link, or send a user into the reset-password flow. If that callback cannot finish, the app returns to login instead of leaving the user on a broken intermediate screen.
If the user cannot sign in:
Enter the email address and password again.
If they forgot the password, use Forgot password?.
If the page shows a reauthentication message, sign in again to restore the session.
If the user forgot their password:
Enter the account email address.
Submit the reset request.
Open the email and follow the reset link.
Set a new password on https://lengrowth.com/auth/reset-password.
If the user is checking an email confirmation or sign-up flow:
Watch for the confirmation email.
Open the link from the email.
Wait for https://lengrowth.com/auth/callback to finish sign-in.
If the callback cannot complete, return to login and try again.
If the user is accepting a company invite:
Open the invite link in the email or from the copied invite URL.
Confirm that the signed-in email matches the invited email.
If the email does not match, use Switch account.
Sign in with the invited email address.
Accept the invite once the account matches.
When a protected page sends someone to login, LenGrowth stores the destination and returns the person there after successful sign-in if the redirect is valid.
When the user opens a confirmation, signup, magic link, or recovery link, the callback page waits for the Supabase session to finish before it sends the person forward.
When a password reset finishes successfully, LenGrowth signs the user out locally for safety and returns them to login so they can sign in again with the new password.
When an invite is accepted, the user is routed into the company they just joined.
Common problems
If a protected page sends the user to login immediately, that usually means no valid session was available for that browser tab. Sign in again and the app should restore the session or send the user back to the original page.
If the login page shows an error after submission, the credentials may be wrong or the account may not have a valid session yet. The page surfaces the exact message when possible.
If an invite link says it is invalid or no longer available, the token may be expired, revoked, or already used.
If an invite page says the invite is for a different email address, the signed-in account does not match the invited email. Switch accounts before accepting.
If a password reset link says it is invalid or expired, request a new reset email from https://lengrowth.com/auth/forgot-password.
If the auth callback fails and returns to login, the code exchange or session wait did not complete in time. Opening the original link again is usually the fastest fix.
If the login or invite page sends the user back to a different route after sign-in, that is usually the redirect memory working as designed. The app remembers the protected page the person tried to open and uses that saved destination after the session is restored.
Related articles
Invitation route pattern /invites/[token]