Any Workarounds To Pass Reset Password Token To The Frontend?

Hi Bubblers,

Just recently found out that we can’t pass the reset password token to the frontend e.g. set it as a state, add it in a text, etc.

We can only use it via the send email function.

For context, what we’re doing is manual creation of accounts through an admin dashboard. We do send the password reset through email but for added convenience, we wanted to simply return the token, structure the URL, and return the value to the frontend where we could simply copy it and send the link to our users — allowing them to not check their emails anymore.

We tried setting the token to a state but it didn’t work, our subsequent workflows, specifically a “trigger custom event x when data changes” just stopped working. The data in the DB changed but the action won’t trigger at all.

Here’s a detailed response from uncle @keith as to why this happens.

As per Keith, the only allowable option seems to be to email the token to a different account.

We could do this but it’ll be a hassle to keep opening our emails just to copy the token.

Honestly, the answer is pretty much there (Not Possible) but I’m just shooting my shot in case there has been a miracle :laughing:

I was thinking, since it’s not allowed to pass the token in the frontend, what if I just create an API call to my own app where I would pass the token value in a parameter and have the data return to the frontend?

Would Bubble read this as a different string completely unrelated to the password reset token? :thinking:

Would greatly appreciate any suggestions and insights!


Yep just do this

1 Like

Will test it out and see how it goes!

And here I thought the reset token can only be used on send email actions.

1 Like

Hey @ntabs! Did the workaround worked for you?

I have exactly the same issue…

@valentin_g simpler is to store token on db.

Tokens would expire in 24 hours. Storing it in the DB would not make sense

Technically the API route would work but we decided not to do it since the frequency of that event happening is not that high so it wasn’t feasible for us

I guess i misunderstood. I thought the goal was immediate use on front end.

I don’t have the exact same use case as you, @ntabs, but the solution I’m about to try may work for you as well. I’m going to send the pw reset email to an un-manned inbox, use Zapier to parse the email, pull token from the body so I can use it however I want from that point.

Possibly the same outcome as the API call, with much less effort.

Huh? Why not just cut out all those steps? Not to mention zap usage.


Agree with @code-escapee here

I disagree here. Setting up your own internal API connection would be much easier than setting up zapier, parsing the email, etc. Not to mention the extra costs of zaps as what @code-escapee mentioned


Why dont you use magic links instead? You can capture the token and do what you want with it.

Whilst not your issue exactly the principle can be applied i belive

My point was to cut out and store it in DB.

I don’t understand why internal API connection keeps coming up. Given the use case I struggle to understand how anything else is being considered or what this means “Tokens would expire in 24 hours. Storing it in the DB would not make sense” @ntabs, what am I missing?

To let the users view the token in the frontend without creating and managing another field.

All password reset / magic link tokens or links expire in 24 hours so creating another field would not be as useful since the token would only be used once. After the link / token has been used, the field would be rendered useless, it’ll be just there consuming space (One could argue though that this field won’t be heavy as it’s just a text field with a short string)

It won’t be heavy at all, can be deleted (now with the bulk updates pretty easily with simple criteria) and is much simpler to setup and admin than creating an internal API connection, is it not? Additionally, the token has built-in privacy rules that an API doesn’t. For some reason, many bubblers overestimate the value of storage and fields in comparison to their true cost.

Managing another field vs. creating an internal API connection is not a choice; the answer is always another field.

Why not just have a field in the DB, Save the token there via a backend workflow, then parse it to front for user to reset their password?
After user resets password, run a workflow to clear the field you stored the token in.

What’s the downside of doing it this way?

1 Like