Tips for Backend Workflows, Privacy Rules & Saving Data with Webhooks

Saving Data Returns from Webhooks with Privacy Rules

Here's my way of saving data returns from a webhook whilst also having solid privacy rules. If you've been working with Bubble and you're using the API connector, and you're using an API that takes a little bit too long for your Bubble app to wait, say for example a transcript or image generation, then you'll be using webhooks to signal to a Bubble app when the API has generated the content that you've been waiting for. In this Bubble tutorial video, I'm going to be using a flux demo that I recorded a week or so ago, but this could be just as easily applied to something like AssemblyAI.

Quick Reminder: Generating Images with Replicate

As a quick reminder, I'm generating an image, I'm sending a prompt through to replicate where the flux model is hosted. And I say I input a webhook value here, and I've already got this webhook set up in my backend workflows and I've already initialized it.

Join Planet No Code for More Resources

And so you see, I get all of this data back. So here's the first way, but before I launch into that, if you're watching this video, it's because you've got an idea and you're trying to build it with Bubble, then I strongly suggest that you click the link down in the subscription and you join us over at Planet No Code because we've got hundreds and hundreds of amazing resources to really accelerate your idea towards launch and beyond.

First Approach: Saving Data on the Front End

So let's just go in and now look at the first approach, which I would say is the simplest. So let me go back to this one, and I'm on my page, and at the moment all I've got is somewhere to put my prompt and generate artwork. So my first approach will be that you save a space in your database for the data on the front end, and that way the creator field or the created by field is populated automatically by Bubble.

Creating a New Thing in the Database

So if I say create a new thing, and this is a demo app that I've used tons before, but I've already got an aiimage type. Now, I can't set the actual image field here because my image isn't ready. I only know that my image is ready when the backend workflow is triggered via the webhook. But what I can do is save the id. So I'll just say id of type text.

Refresher on API Connector and Workflow

Okay, as a refresher, if I go back into the API connector and I initialize this call, I get an id here and I'm saying that it's text and I click save and so that means that in my workflow, oh, back, wrong one. Here we go. I can save the results of step one's id. Okay. And so that then means that, yes, when I go into my backend workflow, I make changes to a thing because I'm updating an existing entry in my database, but I've got a search for it.

Searching for the Correct Database Entry

Maybe this is suboptimal, but I have to say something like this where id equals, and just to be really clear about this, if I go into modify types, it shows me the data returned when I initialize this backend workflow and I get back an id. And this id will match exactly the, well, I matched the ids based on what was sent and what was received. So if I click cancel on there, I simply need to say id equals request data. Id. Now this will return only one result, but there you go.

Updating the Image in the Database

Take the shortcut. So I just say first item and now image. I can take the request data. That's been a while since I looked at their documentation. I think it's output.

Let's double check.

Yeah, output gives me a list of output. Okay, so it's just the first item in output. And so as a quick reminder, how I'd actually save this image into the file storage on my Bubble app is to say output, first item.

Saving the Image to Bubble Storage

Making sure this is what I've missed through reinitializing this, is that this is a, I need to say that this is an image because if I don't do this next step here, which is where I say save to Bubble storage and I give that an appropriate name, you can make that dynamic. Of course it's not actually going to save it to my Bubble storage. It's going to rely on the temporary storage over at replicate. And I don't know that looking up, but that's not going to be reliable because they'll at some point delete the image that was generated. So that's one way.

Setting Up Privacy Rules

And I like that because if I go back into data and I go into privacy, and I actually put a basic privacy rule in here, say user, I don't want anyone seeing the AI generated images apart from users. So I can simply have the most basic expression, which is the creator is current user. And that works because when the front end workflow is run here I am on, just a reminder on this page here. I'm not setting a creator field here. I'm relying on the fact that Bubble has got a built in creator field.

Second Approach: Creating Items in Backend Workflow

Where am I going? Here we go, creator field. And that's set and that's just the common thing with front end workflows is that the creator field is going to be current user. Here's the second way to go about this, which is if you have to actually create the item in the backend workflow. So let's go back.

I've jumbled all of this up back end workflow, right? So I'm not making a change to thing, I'm just creating a new thing. So let's say create a new thing, aiimage. And then I say image. And that's request data output first item.

Ignoring Privacy Rules for Backend Workflows

Remember that's the list of images. Now save to Bubble storage. Okay, so I'm saving it, but I'm going to run into a problem here. In fact, I have just thought, sorry, if we go back to the first one, you are going to need to say ignore privacy rules. Let's just go back.

Right. You're going to need to have this as ignore privacy rules for this workflow. And also you need to say run without authentication in order for the webhook to work because you're searching through all of the images, you need this backend workflow to be able to search through every single entry of this data type in your database in order for it to find the right one with the id. So that's one way of going about it. My second way of going about it is to say create a new thing.

Handling Creator Field in Backend Workflows

And then we are saying create an aiimage and then we're saving the image output first item, because it's a list saved, right? So now we're saving it, but we're going to get into trouble with the privacy rules because it's when an external trigger triggers a backend workflow and there isn't any authentication taking place. There is no creator because it is not run by current user. It's worth bearing in mind that this is different to if a front end user directly through a schedule API workflow. If a front end user directly triggers a back end workflow, then they will be the creator and they will continue to act as current user in that workflow.

Creating a Manual Creator Field

This doesn't work because we've got an external stimulus coming in webhook saying the replicate server has got the image ready. So we need to think of a different approach. And the way that I've done this before is to create another field on here and to say creator manual. And I just label it like that. So that's really clear.

User the reason I'm doing this is because we at no point in Bubble can write or decide or customize or modify the creator field here. So we need to have one that we can customize. So if I go back into the backend, I then need to populate this field. So I still need to use the iD. And so one way that you could do this, although now I'm doing it, it's feeling a little bit clunky, is instead of creating the image there, I'm going to make changes to current user and I'll say replicate id.

Searching for Users in Backend Workflow

So we're doing the same thing basically, which is an id match. But instead of searching through our AI image data type, we are going to search through our users. So we'd save the id and then in a back end workflow we would say do a search for users where replicate id equals data id. Now of course doing this method is only going to work if the user generates one image at a time. Otherwise you're going to get data lost in transit because the replicate id field will be overwritten and then it wants to be first item.

Importance of Privacy Rules

Okay, and once more you'll need to run this with ignore privacy rules because you wouldn't be exposing all that data on your front end about all of your users. But I know maybe an id field is fine. Anyway, it's always better to have your privacy rules really tight and restricted and gradually ease them up, but only when necessary. If you're unsure about privacy rules, I'd really recommend our friends over at flask EU. They've got an amazing Bubble security audit tool, and I'll put a link down in the description for that.

Finalizing Privacy Rules

But our back end workflow now creates it. The last thing we need to do is to match this up with our privacy rules. So if we go back into data privacy AI image, we can add onto here that either is created, which would be the case if we ever created them in the front end, or where this image create.

This image creator manual is current user. And so that way we're saying it's either if the creator field is current user or if the manual field is current user. So there are my two ways of dealing with saving, storing data that comes in through a webhook. Because one of the challenges that you'll face is indeed privacy rules. If you've got any questions, please leave a comment down below.

Conclusion

And remember, head over to planetnoco.com where we've got hundreds of resources, Bubble tutorials galore, courses to help you with developing your app.