Dynamic authentication with the API Connector -- possible?

We have an app that talks to our backend API server via the API Connector. We have username/password authentication handled inside Bubble, but what I cannot figure out how to do is to pass that information into the API Connector dynamically; IOW, what I can’t do, but need to, is to make the API calls on behalf of the Bubble user; they’re currently all run as one single, bubble_user.

Is this possible? I’m not scared of doing custom dev, but I’m also happy to throw some money at the problem, if there’s a plugin in the marketplace tha tmight serve.



Welcome to the community @jfb

It is possible: :smiley:

Thanks! That doesn’t seem quite right – I don’t want the backend to auth against the Bubble app; I want the Bubble app to auth against the backend!

To clarify:

You’re looking to make an external API call but use the user’s credentials vs yours?

We create a username/pwd combo for the customer in the Bubble DB; I want to be able to use that pair to authenticate against the API server.

API server as in your Bubble app?

If so, then check this out.

Make privacy rules around the data fields you store the user credentials on. Then if the user who owns those credentials is going to be the one running the API calls and there is no concern of them exposing the credentials to themselves, then you can run the API calls on the client side (ie: page) but if you are going to need to keep them secure and expect other users who do not own the credentials to access the credentials to run the calls, you will need to run the API calls in the backend workflows and check the boxes for ignore privacy rules.

BTW, please share how the current API connector setup is handling the authorization as there are lots of ways to do so and some allow for dynamic values to be utilized while others do not.

No, the Bubble app itself is a client of the API server, which is a python app running in AWS.

What I understand is the following: You’re able to reach out to the database with the user’s credentials, via the backend. But you want to make that connection via the user/browser?

If so, you just have to change the api type from “Data” to “Action” and toggle the “Attempt to make this call from the browser” on the bottom.

Sorry, I haven’t been clear enough.

Bubble App:
user/pwd live in the Bubble DB here
front end logic, communicates via API Connector to →

API Server:
has a variety of API endpoints, that need to be issued on behalf of the specific logged in user

The Bubble App uses HTTP Basic (for now) to handle authentication, but because the API Connector doesn’t let us set auth data dynamically – or, equally plausibly! we don’t know how – all requests to the API Server are being issued as bubble_user, and not joe_customer or jane_admin or whatever.

Does that help clarify?

Yes, that helps with clarification. I’m not sure how and why would you need to identify users within the api requests, you could add additional data to identify them by id within the request itself.

Yep, that we could do. But the point is that there needs to be a per-user authorization against this backend, and that’s not available in the API Connector, that we can discover.

Neither can we, interesting function tbh.

1 Like

And what is stopping you from implementing this based on a previous reply?

I’m not sure I follow. The API Connector does not seem to allow us to parameterize eg Header fields, whether it’s in HTTP Basic or OAuth2 password. We are not going to do the whole OAuth2 User Agent flow because the API endpoint is part of the same application domain as the Bubble application.

on a side note, do you still have this option when scheduling a single wf? it’s gone on all my apps. it’s still there for scheduling on a list.
I just filled a bug report hoping it’s a bug :man_shrugging:

I do not see it on the action to schedule the backend workflow, but it is still there on the backend workflow itself.

I always was confused about the redundancy of the need for the ignore privacy rules to be checked on the action to schedule the backend workflow as well as being on the backend workflow itself, and I never bothered to test if not checking it on both would cause it to not function as expected…perhaps Bubble found it was redundant to be on both and removed it as I’d imagine if users only checked it on the action to schedule and not on the backend workflow itself, and that caused it to not function as expected, that it would be better to remove it from the schedule action.

Hopefully support will be quick to get it fixed if need be or provide a solid explanation for the recent disappearance from the schedule action.

Shared Headers no…but Headers on the call itself, yes

Just uncheck the box Private on the Headers on the call itself and then you have access to it when using the API call and can use dynamic expressions to populate it.

If your API calls requires authorization to passed through the URL you can do that with the [] to parameterize it

they serve two different purposes for me, usually I prefer to specify it on the scheduling action.

thanks for confirming it’s not only my editor :upside_down_face:

let’s see what will be the reply from support.

Oh, this is promising. Thank you!