Forum Documentation Showcase Pricing Learn more

User-to-User Email Relay?


I have an idea for an app that will allow users to contact each other from within the app. This does not need to be real time. I initially thought about implementing some type of internal messaging system but then realized there’s no reason to go through all that work or deal with the overhead of storing the actual correspondence. All that’s really needed is a way to allow users to email each other without actually divulging their email address - much like Craigslist.

Has anyone done something like this or have any suggestions as to how to proceed?



Hello Steve, Did you have any luck with this? I’m looking for a similar functionality. Thanks


Hi @philip_ferreira. Unfortunately, no, I have not. At the time, I was doing some very preliminary research in anticipation of the need but have since gotten sidetracked into solving a couple other issues. :neutral_face:

I still think that, for my needs, it would be better than an internal messaging system; but I have yet to devote any more thought to it. It might require Sendgrid or another third-party mailer, though. I’ll post back here once I make some progress.


This could be done using Sendgrid (or similar service) as the proxy service, just use Bubble to run the backend. For the app, create a 3 things and use some variation of the following :

    1. Messages
      **4 data types: body [text], conversation [Conversations], from [text], to [text]
    1. Conversations
      **2 data types: messages [list of Messages], participants [list of Participants]
    1. Participants
      **2 data tpes: Users [users], email [text] (optional)

If I’m understanding correctly, you’re essentially creating an internal chat app without the UI and using a email-as-a-service (Sendgrid, Mailgun, etc.) to generate emails to the recipient user. When the users respond to an email, your Bubble app will use the unique conversation ID to route the response to the correct recipient. You would just attach a conversation’s unique ID, for example, to the ‘from’ address (ex. "")

For example:
UserA sends email to UserB from the address
UserB responds to UserA and your Bubble server parses out ID100001 to route the reply back to UserA.

The basic premise is using custom message API endpoints that you create in Bubble, which should allow you to specify a body_format of “html” to preserve the HTML of the email for inbound messages. Similarly, when sending outbound replies, the “body” field of the payload your server receives will contain the HTML version of the message to be sent to the other recipient - a different use-case for a standard messaging app.


Thanks a lot, @supernaturally. You’ve definitely helped stimulate some thinking on this topic.

For my app, I wouldn’t need (or want) to store the content of the messages. I’m interested only in relaying messages between users via email. I’m envisioning a “Send Message” link on a user’s profile page which, when clicked, would open a new message in the message sender’s email client to initiate the conversation. Thereafter, simply replying to an email would send a response to the other user through the platform as an intermediary. Both the sender and recipient would need an account on the system.

The whole idea is to facilitate the conversation, but do so in a way which keeps each user’s email address private - until and unless they explicitly share it with the other party.

As such, it seems the platform would simply need to know who the sender and recipient are on the system. It can then retrieve the email addresses for each party and relay messages between them “on the fly” without storing anything on the system itself. Of course, I’m likely glossing over details, so it’ll be interesting to see what issues arise when I start working through it. For one thing, a simple log with sender, receiver, and timestamp might be useful for troubleshooting purposes. I’ve yet to set up a Sendgrid account, so that’s a bit of a “black box” to me right now as well.

Thanks again for your input.


Happy to help. Its sounds like you’re thinking about things in the right way. If relaying emails is the only goal, you might just get rid of #1 (Messages) altogether. You would need at least #2 (Conversation) to store the participants engaged in a specific dialog instance.

Sendgrid is pretty easy once you get the hang of the API documentation, but it can be overwhelming at first. Looking into things a bit further - Sendgrid has an X-Message-ID that is a part of each email’s message ID and is returned in the mail send response for the API. Each email/send receives a unique message ID. When it comes to the Event Webhook, each email event will include this message id so that you can relate the event to its email.

For example: when you send an email, you receive only the first part of the message ID as follows: X-Message-ID = 8XXXXXXXsdfajkjkdfa2

Once the email gets to SendGrid, the second part of the message is created. sg_message_id = “8stGv8SRT76NJeVxk9oVQg.filter0808p1mdw1-26392-590B69BC-C.0”

If you want to create your own unique code for each email before sending the email and track it after the email is sent with Event Webhook, you can set custom arguments with v3: or unique arguments when sending via SMTP API or v2

Using that information, you should be able to work to thread messages together via Bubble. It may sound fairly involved, but it is very doable. You would basically be building out a Craigslist-style relay :slight_smile:


Thanks @supernaturally and @shot. I’ll give this go, it sounds exactly what I need.