Client side api calls

Does anyone know the guidelines with regard to making API calls within our workflows? Is it safe to make calls with sensitive info, or should those calls always be made on the server side using (API Workflows). For example if I use stripe connect to connect to users, I get a redirect… I then have to take the code returned from the URL redirect make a API call to obtain the users Access token, refresh token, stripe user id, public key, etc… should that API request take place under (API workflows) on the server side or is it safe to do on the client side with a regular workflow??

Some good questions!

I assume you’re talking about API calls made with either the API Connector or the equivalent in a plugin.

The Bubble reference on this has some hints on what happens, but doesn’t specifically say. It looks like parts of the API call are collected on the client side, and sent to Bubble’s server to make the call to the external API.

So yes its safe to use a regular workflow, so long as you are careful about which data gets exposed to the client.

Relevant parts of Bubble reference for API connector …

An API call’s URL is never sent to the user’s browser. Call headers and parameters are only sent to the user’s browser if you mark them as ‘client safe.’ Parameters, such as a secret API key or password, should never be marked as client safe. If you mark a parameter as client safe, you will be able to assign it dynamically in the Bubble Editor. A search term in a search query is a good example of a client-safe parameter. The call’s body is sent to the user, thus it is not client safe.

This is the call’s URL. It is not client safe, meaning the value is not sent to the user’s browser when the call is made.

This is the call’s body. It is client safe, meaning values are sent to the user’s browser when the call is made.

Click to add and configure a new HTTP header. Headers are not sent to the client by default, but they will be if you enable the Client-safe checkbox.

Click to add and configure a new call parameter. Parameters are not sent to the client by default, but they will be if you enable the Client-safe checkbox


Thank you for taking the time out to answer my question!!! very helpful. So to be clear if we need to make a private request (request not viewable in from the browser) but also need to expose the parameter in the editor. Is an acceptable method, exposing the parameter and placing it in the url as a querystring?

this would allow us to edit the request in as needed while keeping it private? Is this good logic?

Also what if we schedule a API Workflow with parameters? Are those parameters sent to the browser?


I’m not sure exactly what you mean, I’ll explain more.

Bubble server to API

Making a GET call can have:

  • query parameters, these are part of the URL sent by the server, so can be seen by routers, etc.
  • headers, which aren’t visible to routers (assuming a https call). This is where authentication usually takes place.

Making a POST call (for example to the API workflow) can have the same as GET, plus:

  • body, optionally containing body parameters. EDIT body data isn’t seen by routers either.

Bubble client (user’s browser)

The parameters set to Private don’t allow data from the page, so the field is missing in the app editor when setting up to invoke the call, and should be filled in by the server from the values in the Plugins section.

1 Like

I make a post request… uncheck the private box… this would expose the parameter to the client? example from the picture i uploaded… key: confirmation value: signature, is not marked private so it is exposed to the client. but I also checked Querystring… this places the request in the URL which isnt sent to the users browser . So in this example can the User see the key value pairs if they wanted to?

Yes, and so can anybody else on the internet (theoretically), URLs aren’t private unless going only inside a private network.

ok what is the best way to pass parameters from the client to the server?? If I schedule an API workflow that contains parameters(confirmation/value). and then Run the workflow current date/time passing along those parameters(confirmation / value)… would they be exposed to the user?? Im just trying to keep fields safe and editable at the same time.

Anything on the client is already exposed to the user. But, in general, dynamic values and conditional expressions are run on the server as well as the client, so what you send to the client can be constrained… for example “Current user’s measurements” won’t let out the wrong person’s secrets.

A condition on a workflow event “Current user’s role is in list of allowed roles for this action” would restrict which users on a page can initiate the action.

If the API call needs to retrieve data from the database, it does so with the current user’s authentication, and according to the docs, is sent to the browser, so yes the user potentially can see that data too. Just not the server-only secrets.

If the API call needs to happen with server-only secrets from the database, i.e. data that you want kept secret from the current user, then you’d need to run this from an API workflow instead.

I’m not 100% this is accurate … it could do with clarification from team Bubble.

1 Like