Rest API calls without the API Connector plugin

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.

function(instance, properties, context) {

if( === false) {
    async function postJSON(data) {
    const response = await fetch("", {
      method: "POST", 
      headers: {
        "Content-Type": "application/json",
        "Authorization": "Bearer _*_API KEY_*_"
      body: JSON.stringify({
         "model": "mixtral-8x7b-32768",
         "temperature": 0.5,
         "messages": [
             "role": "user",
             "content": `${properties.prompt}`
try {
    const result = await response.json();
    return result.choices[0].message.content;
  } catch (error) {
    console.error("Error:", error);
          .then(function (data) { 
       		let el = '<div>' + data + '</div>';
  console.log("ai api call"); = true;


The rest is up to you. :wink:

1 Like

Your are doing this client side? Your key are not secure…


It’s just an example. The rest is up to you :wink:

1 Like

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


I’m thankful for the post…

Does it return a thing? Are you initialising the api connector so you can use the values?

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

1 Like

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.

Question about secure keys in Bubble plugins.
In the shared section of plugins you can add the key to the header.

Dynamic values (API key, tracking code, etc.) can be inserted between * (for instance API KEY) and will be available to users in the Plugin Tab.

Is this not safe?

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?

I’ve found this code in a plugin:

window.xano = new XanoClient({
‘apiGroupBaseUrl’: ‘API Group URL’,
‘dataSource’: ‘Xano Data Source

Is this secure?

In the plugin editor we can import API calls from the API-Connnector.
Are they secure?

Is it safe if I use this?

this is not secure. injecting random untrusted code in the page is not secure.

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

1 Like

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.

Of course I’m aware that the API connector is one of the best Bubble feature and I know the difference between private/public parameters.

Then all AI templates and plugins are unsecure.

your example does something not secure so everyone must be doing something not secure. sounds good :upside_down_face: