3 easy mistakes to make with the Bubble.io API Connector

Common Mistakes with the Bubble.io API Connector

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.

Protecting Your API Key

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 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 the API key.

I'm using an example here of the OpenAI API. I mean, you know some I can put in limits and you should have limits in place on your account. But it still means that someone can wrap up a bill on my behalf using my OpenAI key and I want to stop that. 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 send. You can kind of dynamically insert data into that your users are submitting through your front end. So that's protecting your API key.

Content Type Headers

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 the documentation. You might have to set this to something different.

Using API Calls as Actions

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 I create and the times that I work with people on the Bubble coaching call, we don't actually want it to run this data. We want it to run as an action and you can 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 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 the 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 user has to click a button for example in order to run that API call. So very important if you're being billed for the usage.

Conclusion

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 Planet No Code where you can find hundreds of Bubble tutorial videos just like this one.