Hey @austinm911: I think you might be a little confused by Bubble’s (odd/poor) nomenclature around backend workflows (which are also referred to as “API workflows”) versus calls made to some (typically) external API via the “API Connector”.
“Backend workflows” as they are now known in the editor (found at the bottom of the page search menu) are workflows that run on the Bubble server. They are also referred to as “API workflows” because such workflows can also be exposed as API endpoints (so that other web applications - or even your own application itself - can communicate with your app via HTTP protocols such as GET, POST, etc). But of course backend workflows do not have to be exposed as public endpoints, they can also just be workflows that run on the server side that are available only to your own app.
It doesn’t help that, in the backend workflows view, such workflows are labeled as “API Workflow - name_of_endpoint”.
We trigger a backend workflow from the client side using the “Schedule an API workflow…” actions. “Schedule an API workflow” simply means “trigger the backend workflow in question at some particular time (which can in fact be now)”. The “Schedule an API workflow…” actions do not return data from the backend workflow. What that action returns is an ID for the scheduled workflow. (The utility of that is that we could use that ID to cancel the scheduled workflow. That’s really the only purpose of that value.)
So, that’s what backend workflows are.
Now, these are not to be confused with the mechanism Bubble provides us for making HTTP GET, POST, etc. calls to (usually) external web resources. This is called the “API Connector”.
Calls to such web resources via the API Connector can be made in one of two ways: Either via an action in a workflow (where they show up with the names you’ve given to a particular action call under Plugins) or “as data” by referencing them in an expression built in the Expression Builder, using the “Get data from an external API…” dynamic expression.
Whether a given API Connector call (“API call”) is available as an action or as data is configured when you set up your specific API call in the API Connector. (See image below.)
Note that there’s nothing keeping you from having a call available by both methods (just duplicate the call and set one to “Use as Data” and the other to “Use as Action”).
Here’s where I think you might be getting confused: An API call configured as an action can be used in either a client-side (in page) workflow or backend (“API workflow”) workflow. And the same is true for an API call configured as “data” – anywhere you can write an expression, you could potentially use that API call via the “Get data from an external API…” expression.
That is: API calls made via the API Connector do not have to made in the backend. They can also be made client side. (On the client side, note that some API calls might be made directly in the page while others may need to be brokered by Bubble’s servers, however, the API Connector abstracts this detail away.)
So, anyway, if you want to set List Shifter’s Custom List to be some result from some API call, you can either:
- Make the API call (the actual API call, not “schedule backend workflow”) in the action step before Set Custom List and then set Custom List to the “result of that step”.
- Configure that call as “data”, and then you can simply use the “Get data from an external API” in the “Custom List” field in Set Custom List. (Though note that in either case, you must configure the type of that field in List Shifter’s main interface, under Process List Type or else you’ll not be able to select any value.)
If for some reason, you desire to make the API call in a backend workflow, you won’t be able to return any values to the page via “Schedule API workflow”. What you would have to do is either (1) store the response in your database and retrieve that in whatever page you need it (this doesn’t really make any sense) or (2) configure the backend workflow in question as a publicly available endpoint.
When you configure a backend workflow as an available endpoint the “Return data from API” action becomes available to you. And what that action does is configures the response from your endpoint. And now you could go into the API Connector and configure an API call that calls your own app’s endpoint that you just built.
But I can’t see any reason to do that in this instance. However, if you’re interested in that topic, I touch on it in the video linked here: FLOPPY: Plugin for localStorage, sessionStorage, IndexedDB storage, List Creation/Manipulation, Iteration, and More! Now with even more video docs! - #128 by keith