I made a similar idea post a while back about a similar feature request, but for custom events. Apparently that’s being worked on as we speak. This same idea should extend to API workflows, in my opinion.
Scheduling API workflows are useful, but they lack the ability to return values (like any other API call can do). For example, what if I want to schedule an API workflow and use its “returned data” in the following action step?
CONTEXT
We can return data from API workflows but only to API requests…
When scheduling an API request in a workflow, if I console log the “result of step X” from the API workflow, I am returned with only it’s ID, and nothing about what it returns…
In other words, I can’t use the server side to my advantage on the browser WITHOUT saving things to the database, which is very unfortunate…
because there are certain situations where we need to generate some data to display on the page but it requires making one or several API calls using a token that cannot be exposed to the client side.
TEMPORARY WORKAROUND:
For me, I have no choice but to use an external service to generate the data because it requires a token which cannot be exposed to the client side. If I generate the data on the client, then the client can use the JWT returned from the API call to view data that they should not have access to.
Unfortunately, I cannot save the data to the user to display on the page because it is a huge chunk of data and that cannot be processed quickly by the database. As of today, the only solution to this is to use an external service. Creating a plugin is also not a solution because server side actions have a time limit of 30 seconds, which is not enough time to generate the data I need to create.
THE SOLUTION(S)
Solution a) let us return data from a server side api workflow and use it directly in our workflows
Remove the 30 second time cap for server side actions. This wall has prevented me from creating many great things in Bubble. It’s now bitting me in the butt again!
Yeah - Been on the radar for quite some time but has never come to fruition. My guess is this is another “power user” feature that will take backseat to AI/Native App.
The problem lies in the action - Schedule an API workflow, which Schedules an API worfklow. The system is expecting a scheduling of the workflow, not a triggering of the workflow.
Sure, a lot of us use ‘Schedule API workflow’ to current date time, so it runs immediately. But I feel like this is more of a 2 birds one stone thing, you get to schedule workflows and trigger them with one action.
You need to call the api instead of scheduling it.
You can put your Bubble API (https://appname.bubbleapps.io/api/1.1/wf/workflow_name) in the API connector, initialise it, and then you can ‘call it’ in your workflow like any other API and it will return the data.
The issue with doing that is security, for me. It seems like when an API call is made, it shows up in the Network tab (https://yourappname/apiservice/doapicallfromserver). This has been exploited in my app before, because they were able to make the call to this URL on postman to generate a token. Although, the API in question was being used as a “Data Source” on a plugin element. In other words, they were able to see the input fields, the destination URL and just change things around to get what they want.
Not sure if it shows up like that everytime, there’s no documentation so I have to manually test everything myself…
Yeah, but this is a pain. Bubble knows what parameters a backend workflow takes. It just needs a new action ‘Run backend workflow’ that runs the workflow immediately and, if return data from API is in the workflow, returns that data. When return data from API is modified, so too should the Run backend workflow action output. Heck, even a button that allows us to quickly import a backend workflow’s required input into the API connector would be a lifesaver for me.
I’m not aware that there would be any big security issues. API calls are mostly routed through Bubble’s servers, only in a small subset of scenarios are they allowed to run directly clientside. There is some information on the manual. Just ask the Gitbook AI.
You do have to make sure that your API call is secured correctly.
Try putting a text parameter on your API call, setting it to ’ secure password ’ on the API connector and checking the ‘private’ checkbox, and then running the workflow only if the input parameter is ’ secure password '.
Having a private parameter in the API connector will ensure that the API call is ran server side, and only the response will be delivered to the client. It wont be possible to run it from Postman, not easily at least.
If API connector calls ran clientside then we’d be exposing Stripe Secrets all the time.
But I’m not sure whether i’m properly understanding your problem. Let me know if the above helps.
I definitely agree it’s a pain. I would appreciate a quality of life improvement, but hey, it works.
The problem I ran into is that my API call I made in the API connector was exposed to the client side under the URL mentioned before /doapicallfromserver. The parameters were exposed to the client. So all a user has to do is ping this url and change the parameters themselves, in order to generate tokens for users other than themselves. I wonder if adding a private key will works but that doesn’t sound very reliable. I’ll give it a try
Just saw this. It’s not reliable because if I can’t use dynamic values without exposing the parameters to the client side, then I’d have to either create duplicate API calls or duplicate endpoints that do the same thing. It would bloat my backend workflows or API connector and make it untenable
It does not matter if you expose some parameters to the client side, if you are using an API token/secure key to authenitcate the calls and this never reaches the client (I guarantee you that it doesnt, thats the whole point) then people will not be able to replicate the call.
Go on your settings > API > Public API Endpoints > Generate new API Token.
Generate an API token, and use it to authenticate the calls.
New trick is to use the APP connector instead of the API connector to make stuff quicker. The trick was laying in plain sight.
If the problem isnt secure API authentication, but rather that you dont want to expose the dynamic parameters to the client side, then thats another problem.
You can’t say it doesn’t matter if parameters are exposed to the client side for an api call which is supposed to be happening on the server side. For instance, if the parameter is an identifier used in API service (account ID) than the person on the client side can swap this accountID with someone else’s ID to return data they would never have access to becausr they don’t have the API tokens. It’s a huge security risk that these are exposed to the client side (they are, I’ve seen it with my own eyes)
In fact, I’ve replicated the problem many times and have implemented widespread fixes in my app. Be warned reader, apis accessed using “Data” and not “action” (in a repeating group for instance) can change the API keys which are not private and thus manipulate your calls. It can be worked around, but it’s a very important piece of information which I did not find to be documented.
I’m well of aware that we can generate tokens in settings. This is different though, I’m talking about a way to get stuff by copying calls and swapping parameters from the client side. I can show you all exactly what I’m talking about on video if you’d like
So, does the above method of using the App connector hide the contents of a parameter completely or not? Alternatively, could you just save the result of the backend workflow to the database as an intermediary step?
In theory, anything on the page is accessible to the user e.g element states, workflow actions. Any parameters in the app connector wouldn’t be private, aside from the API key if added from the App Connector settings area. If you need private parameters, you can call the app using the API connector and set the parameter to ‘private’, or, if the parameter needs to be dynamic but private,
run the API call in the backend.
And just to make sure, if the API is only being run in the backend, there’s no point in using private parameters on any aspect of the call right? For example you can hide the URL by using [URL], setting the URL in the key, then marking it private. You can technically do this for the entire call. Any point in doing this if the API is only being run totally on the backend? Thank you so much!
I’m fairly certain this is only if you’re using the API on the frontend. If you’re using a backend workflow that uses an API as Data instead of Action, with all fields private except for one dynamic, and the dynamic field only comes from your own DB, there’s no security risk.
