Limited Time Offer: Watch All Our Bubble Tutorial Videos for Only $99 per Year!

Each day I work one to one with Bubble app builders just like you. And here are the three most common mistakes I see being implemented with the Bubble API connector.

Mistake 1: Insecure API Key Placement

First of all, when you are using an API key and most third party services will use an API key, it's how they match your usage of their service to the billing and it's something that you don't want getting into the hands of your users. So it would be a mistake to put your authorization and then API key in the shared headers for this call because then that would be accessible to your users if they open up their browser developer tools they can access to API key. I'm using an example here of the OpenAI API I can put in limits and you should have limits in place on your account, but it still means that someone can rack up a bill on my behalf using my OpenAI key and I want to stop that.

Mistake 2: Incorrect Content Type

So make sure that you're taking and making use of the tools that Bubble gives you in order to keep things private. So for example, private key and header Bubble knows to keep this field private and not to share that through the browser to your user. And then if you're adding in body parameters and you've got them ticked as private, they are also of course then private, but they're not then data that you can kind of dynamically insert data into that your users are submitting through your front end. So that's protecting your API key.

Mistake 3: Inappropriate Use of Data vs. Action

The next one is about content type as a shared header. Now recently I saw Bubble had done an update where you no longer need this. Let me prove it to you. So I'm going to reinitialize the call and I get a response back. Now looking at the OpenAI API documentation, I have to have content type application JSon. We no longer have to manually put that into Bubble.

It is an assumed parameter. However, do watch out because although I'd say the majority of services out there do use content type application JSon, some want the data in a different format like a form and so watch out for in their documentation. You might have to set this to something different.

And lastly, when you add in a new call into an API, it sets it as data. Now that is useful in some instances, but again, 90% of the videos that I create and the times that I work with people one to one on the Bubble coaching call, we don't actually want it to run as data, we want it to run as an action.

And there's some flexibility with that. But in the majority of cases if you want it to have a place in your workflow as a workflow action, you have to use it to set it as used as action data does have some applications. I'd say the main reason for using action over data is that you're then in control of how often that API is called. For example, if you were to set it as data and then you would have that as the data for a repeating group on your page every single time the page refreshes, you run the risk of really racking up a big bill with whichever API you're using. So if it's an action, you know that a user has to click a button, for example, in order to run that API call.


So there you have it. Those are my top three mistakes that people make using the Bubble API connector. If you're learning Bubble, there's no better place to do that than, where you can find hundreds of Bubble tutorial videos just like this one.

Latest videos