You can use JS native Fetch(endpoint) to call Rest APIs without the API connector plugin. This is very useful because you can use async await. Here’s an example with the Groq API for 10x faster AI calls.
a tip that does not warns about the main problem that brings to the table is more like a disservice. there is not an “up to you” part that can secure the secret key client side without adding a secure server.
it is a method that can be used only for requests that don’t have secret data so an example of this kind of request would be better.
there is also the thing that the example does not handle response status and inject untrusted code directly in the page and that’s a potential security vulnerability
it’s not returning data or using the api connector. If you want to use fetch directly on the client and return data the best path is to make a plugin with an element action. when fetch is complete you publish the data to the element’s states and trigger an event so that in the editor you can start workflows as soon as there is new data available
The example code returns data. The result of the API call. It’s not returning a Bubble thing and it’s not use the API connector. That’s why a give this example.
My example code is like hundret of thousands example code in Rest API documentation.
And of course ‘it’s up to you’ how you implement secure keys. I just want to show how to use JS fetch. for Rest API calls.
your code example does not return data to be used in the editor (as data or action result), you are just using it to inject untrusted code in the page directly.
adding secret keys in the page header is not safe, they need to stay on the secure server, for example a server side action that defeats the main purpose of using fetch on the client.
again your example should be about a public api without secrets. using an api with secret keys like groq directly from the client brings security issues that you are dismissing with “it’s up to you” while there is nothing that can be done without a secure server.
Thanks for clarification about keys in header. The Bubble documentation should be better for this issue. Imho the lack in the documentation is more dismissing than a simple example code like mine.
A lot of plugins or templates in particular for AI are doing the same. Why do you think a response from ChatGPT or any other AI, return untrusted code?
it’s up to the platform that you use. for bubble it’s the api connector that automatically uses a secure server to hide the secret keys. if you suggest a way to not use this feature you should at least warn that there is an important security feature missing and that the user should take care of it
read the documentation: that is a client side sdk, the info inputted is meant to be public. there is not a secret key that needs to be protected
if you don’t expose secret keys to the client it is secure. I’m sure in your bubble experience you have seen the difference between private/public parameters with the api connector. everything marked as private stays on bubble’s secure server and it’s not exposed to the client. this is one of the best built-in features of bubble that a lot of other platforms are lacking (other platforms have a server proxy but it’s for a different purpose and all parameters are public and exposed)
if you assume replies from an llm are not untrusted code I can only wish you good luck with that.