# Verification Code (via Email / SMS)

**URL:** <https://forum.bubble.io/t/verification-code-via-email-sms/351827>\
**Category:** Need help\
**Created:** [December 12, 2024, 5:16am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827 "2024-12-12T05:16:42Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![thethinklab.au](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/thethinklab.au/32/156912_2.png) [@thethinklab.au](https://forum.bubble.io/u/thethinklab.au)\
**Post date:** [December 12, 2024, 5:16am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827/1 "2024-12-12T05:16:43Z")

</div>

Hi all,

I’m building a form where I need a user to verify either their mobile or email. The idea is that the user can choose which, and they’ll be sent a code to enter. The experience should be the same for both. Also, given it’s middway through a multi-step form, I don’t want them to be sent any ‘links’ that they need to click to verify.

The advised approach from this forum is to:

1. On Submit:  
a. Create a user account.  
b. Populate a ‘verification\_code’ field on the User type (using a random string generator)  
c. Send the code to the channel (Email/SMS) chosen by the user.
2. Have the user enter the code into a field and compare the value with the ‘verification\_code’ field.

My questions are:

1. How secure is this? Wouldn’t a malicious actor be able to inspect the User data type to see the code they need to enter (avoiding the need to provide a valid email/phone)?
2. Many of the posts I am following are from a few years back… Given it’s late 2024 is there a better ‘out-of-the’ box solution that’s consistent across mobile/email?

Thanks all 🙂

---

<div class="post-metadata">

**Author:** ![johnny](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/johnny/32/203020_2.png) [@johnny](https://forum.bubble.io/u/johnny)\
**Post date:** [December 12, 2024, 7:22am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827/2 "2024-12-12T07:22:54Z")

</div>

Hey @thethinklab.au,

This is how I usually do this is:

1. Have a backend workflow I use to send the verification code: generate the Calculate Formula or whatever it’s call field, then send the code to the proper channels.

2. I would have another backend workflow used to check if the code is correct and then return the response (I use the Bubble App Connector for this and run it using an admin token) and then continue the flow from there.

Just make sure the verification code is actually private to the user via privacy rules.

---

<div class="post-metadata">

**Author:** ![thethinklab.au](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/thethinklab.au/32/156912_2.png) [@thethinklab.au](https://forum.bubble.io/u/thethinklab.au)\
**Post date:** [December 12, 2024, 9:36am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827/3 "2024-12-12T09:36:56Z")

</div>

Thanks!

Another question, do you use fields on the user type to manage and compare the codes? I saw another solution where that person created a whole seperate data type call “verification code”, which has a “related user” field…

Not sure on the merit of this?

---

<div class="post-metadata">

**Author:** ![johnny](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/johnny/32/203020_2.png) [@johnny](https://forum.bubble.io/u/johnny)\
**Post date:** [December 12, 2024, 10:05am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827/4 "2024-12-12T10:05:31Z")

</div>

I personally just use it on the user data type because it’s only one field

I think it’s part personal preference too

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/bubble/original/3X/2/8/2847faa74692c2ffa5d939d3dc3724cdd060d247.png) [@system](https://forum.bubble.io/u/system)\
**Post date:** [February 20, 2025, 5:17am UTC](https://forum.bubble.io/t/verification-code-via-email-sms/351827/5 "2025-02-20T05:17:30Z")

</div>

This topic was automatically closed after 70 days. New replies are no longer allowed.
