I’m not sure if I’m using the correct terminology to describe this, because I haven’t been able to find this in the forums at all and I’m guessing its fairly straightforward.
I have an API workflow that has several steps and can take up to 30 seconds to execute. When I trigger this workflow from a page workflow I was wondering what kind of feedback I can get that it has completed or any other data it may return just like an external API.
It almost seems too obvious that I’m missing this. I see return data from the API as a workflow API action, but I don’t see where I could retrieve that data anywhere else?
You’re correct. There’s no returned value from an API Workflow called in this way (scheduled from your page / Bubble app). What are called “API Workflows” in Bubble might be better termed “server-side workflows”.
These perform actions entirely on the Bubble server and not in the page itself and hence can be run when the user is not present, on a schedule, etc. (You know this, of course.)
Also, these workflows can be exposed as publicly available endpoint and serve as a workflow API for your app. The “return data” workflow action is intended for that use and has no application when an “API Workflow” is scheduled within your Bubble app.
However, what is less commonly known is that, once exposed as an endpoint, your app can actually call its own endpoints via the API Connector. This seems like a wonky thing to do (and if “return data” did work with scheduled workflows, you wouldn’t even bother to do this), but it’s useful and essential in certain cases.
I do not have a “simple” example of this to share, but I talk about this use case and show how its used at the 40 minute mark in the video linked below. You can use this technique to run an API Workflow in a way that returns a value you could use in your page / know when the workflow has completed.
(Obviously, this is not that useful if what you’re doing is scheduling an API Workflow on a list. There are other workarounds for that case, such as writing some data object and checking for its existence.)
Check out the 40 minute mark in the video below for an example:
Thanks for this great response! I was hoping it was something I was missing inside the editor, but I guess not. This is the first documentation I’ve seen on the subject of querying workflows, so thanks for that.
Yeah, this seems a touch silly. Confirmed that Return data from the API is only for publishing data in response to external API calls - which can indeed be consumed by a bubble app via the Bubble API connector as @keith points out. Not allowing this published data to be also consumable internally (without the extra steps of using the API connector) is a big missed opportunity for modularizing backend functions.
For example, I need a backend function to text someone but that message needs to be sent from one of a couple possible phone numbers depending on context. If API workflows could directly return data internally, then I could do something like:
where I’m selecting the “From” number in one workflow then using the result in another that’s operating on a list of recipients.
But since we can’t do this, I either have to setup an external call into my own application via Bubble API connector OR do everything in one workflow like:
with the downside we’re required to carry the context for determining which phone we needed into downstream events (that need to know which FROM phone is in play). This expands the workflows needed to achieve the same result from 7 in the first case to 10 in the second. Not a big deal but the increase in workflows is significant when the number of related downstream operations we need increases - that is, something that could have been implemented in n + k actions currently requires n * k actions. And that’s if it’s even straightforward to inject our context into a downstream action condition - remember, Bubble doesn’t support PEMDAS ( Please Excuse My Dear Aunt Sally) order of operations… so it’s always my guess if
Condition 1 or Condition 2 and Context 1 logically results in
(Condition 1 or Condition 2 ) AND (Context 1) or
(Condition 1) OR (Condition 2 and Context 1)
So layering our context upon actions that have their own preconditions gets tricky (usually too tricky to bother with).
In conclusion: please please expose API worflow responses internally @cal
It’s been years since I’ve looked at this, but in short. YES. This is still how it is done in 2022
It may offend your sensibilities, but setting up your API workflow to be public and to return text containing a JSON structure which you can then then call from your app using API connector is a totally valid way to achieve complex actions server-side in your app. You man find that it is ultimately easiest to build and maintain (depending on your use case) a backend data flow this way.
It’s hard to imagine, but API workflows (now ‘backend’ workflows) used to be even more limited than they are. There are very good reasons why things are structured the way they are. Could they be improved? Heck yeah, but I wouldn’t hold my breath too long for that if I were trying to roadmap how my app will do backend stuff
Just bumping this up as with all the new stuff Bubble is adding, it would be really nice to get return values from a backend workflow instead of using workarounds.
