How To Return Data From Backend API Workflows (no manual API connector)

[georgecollier]

TLDR:

• calling backend workflow from API connector is unreasonably tedious
• app connector auto-sets up and syncs fields
• result/returned data from backend workflow can be used in following front-end steps

Returning data from backend workflow in front-end without manually setting up API connector calls

I have a lot of feelings today, as I’ve learned something that would’ve saved me hours of time had I known earlier, and it feels like something that only a handful of people know about (based on the comments on the custom event return data announcement)

If you want to call a backend workflow in the front-end and use the return data from API action to get data from the backend workflow into the front-end, people generally use the API connector. That might look something like this:

You can then make an API call to your own app. This has a few problems:

• time consuming to set up and initialise
• generally requires you to manually add relevant data into the workflow to ensure it runs without an error
• if you want to change a parameter even slightly in the BE workflow, you have to do the same in the API call

Bubble App Connector

This is a fairly quiet feature/plugin from Bubble. It was designed to connect two different apps together with data / workflows. However, you can actually use it to connect your app too… itself.

With this method:

• you can trigger backend workflows to run synchronously from the front-end
• as a consequence, you can use the returned data in following front-end steps
• any backend workflow changes are easily updated in the API calls

Here I have an arbitrary backend workflow that I want to call from the front-end:

It takes a text field, a User, and a dateOfBirth. It then returns data - for this example made it always return ‘30’ but it could return as many things as you’d like:

Now, let’s install the App Connector plugin and set it up. It’s straight forward and you’ll only need to do it once.

Then, ‘Refresh app metadata’ and add the relevant backend workflow:

Let’s go to the page where we want to call this backend workflow.

We use the ‘Run (appname) (workflowname)’ action.

This will give us the fields to fill. It will also verify that we’re providing the right field type (if I put a text in the dateOfBirth field, it’ll stay red as it requires a date).

Then, we can use the result of this API call in the next step:

And that’s it. It behaves exactly like an API call from the API connector. If you change the backend workflow’s required input or the data it returns, just ‘refresh app metadata’ in the app connector plugin area. One note is that ‘refresh app metadata’ doesn’t appear to work on branches other than the main development branch, so if you don’t see a new workflow there or it’s not updating as expected try refreshing on main.

I just can’t believe I only learned about it today and it’s been kept so quiet in general!

[Benjamin_Rodgers]

It’s really no shock that the Bubble App Connector flies under the radar for such a specific issue. Dealing with data return in Bubble can feel like you’re hacking together a solution because, frankly, it’s not set up to be easy.

Using Bubble Workflow APIs to safeguard keys or for tasks like Base64 encoding is a big headache the first time around, and even though the App Connector helps, it remains a stopgap.

The irony of using the App Connector, a tool not originally meant for this, underscores Bubble’s limitations. Bubble needs to simplify data return from API calls directly, without extra plugins, so we can skip these hoops in the future.

Until then, thanks for shedding light on this workaround. It’s a big help for those of us in the trenches.

[georgecollier]

I’m noticing that this fails when trying to pass an option set to the backend (e.g the backend workflow takes an option set ‘User Type’ parameter and the run app connector action also takes a User Type parameter:

Error connecting to a Bubble app: Invalid data for key Type: could not parse this as a User Type. The action won’t let me provide the OS display as an alternative to see if that worked.

Anyone have a solution?

[Benjamin_Rodgers]

The “app connector” plugin might not handle option sets well because they’re not dynamically shared between apps. You could try sending the option set display data as text, and then filter by display on the receiving end.

[georgecollier]

Yeah, I know that’s the cause. Thing is, Bubble’s app connector plugin actually forces you to pass the option set value if the BE workflow takes an option set, so they’ve obviously thought about this scenario but just not made it work.

[Benjamin_Rodgers]

Just tried it and found something interesting: if you pass the option set’s display data, the system correctly accepts and processes the option set as intended. However, doing so triggers a misleading error in the editor, which suggests a datatype mismatch when you attempt to align it from text to option set. This looks like a bug, since the functionality clearly exists but is flagged incorrectly.

[georgecollier]

Support actually just replied to the bug report which would explain this:

The behavior you observed is a known issue with option sets where options sometimes use an underlying ID instead of the display value. The underlying ID is set when the option is first created, so there may be a discrepancy between the two if you have changed the display for the option. So, this may cause unexpected results when option sets are used within searches and in API calls.

You can determine the underlying ID of an option by exporting your application’s JSON, opening the resulting file in a text editor, and doing a text search for the display of the option (or something else that would identify it). The object containing that display will be the definition of the option. If this contains a “db_value” field, the value for that field is the underlying id. Otherwise, the underlying id is the key pointing to the option’s definition in the containing values object.

[Benjamin_Rodgers]

That’s quite the technical response from support, lol. Not sure how practical it is, but it’s fascinating to peek behind the curtain. Ideally, they should streamline passing the option set display (like when sending option sets to a page parameter) since it actually works, aside from triggering an editor error.

[stefano]

Fantastic post!
This will help me a lot
Thanks immensely @georgecollier

Now I am facing an issue and wonder if you guys faced the same at some point: I can’t seem to add one of the required parameters on API Call.

Here’s the Backend API:

As you see, I have two parameters, one being a text and another one of my Data Types.

On the Frontend, though, I only have the option to enter the text parameter.

Would you know why?

[georgecollier]

@stefano

Would you know why?

You need to refresh app metadata in the app connector plugin. You must do this any time you change the parameters that a backend workflow used by the app connector takes.

[stefano]

Thank you for your prompt reply.

I did that, several times. Also allowed access to the data API on the setup. But nothing seems to work.

[bidlist]

hi thank you for the thorough post.

I was struggling with this for 45 mins and nothing working. Turns out I had a space in my API name. Which got converted to %20 and it was causing the API workflow to not be found.

The error looked like this: Workflow error - Bubble App Connector error: 404 - {“statusCode”:404,“body”:{“status”:“NOT_FOUND”,“message”:“Workflow not found api%20_test”}}

I replaced the space with an underscore and it works now! Thanks again.

[randomanon]

Hey @georgecollier , thank you so much for this awesome tip which I hadn’t seen anyone else come up with. Would calling your own backend workflow using the App Connector expose non-private dynamic parameters which would otherwise be kept private by virtue of being in the backend? Also, what’s the difference between running the front/back end workflows synchronously and returning data in the way you’ve outlined versus simply saving the data from the API to the database, and then retrieving it from the front end separately? My main concern would be that ideally, I would avoid having to expose my workflow publicly (even if requiring authentication, since I don’t like how admin tokens are handled in Bubble). Thanks so much for being such a great asset to this community!

[S-J]

Hello @georgecollier,

Thank you for this method, it works very well !

In addition to that, we tried it on a recursive backend workflow (basic test workflow that would call itself to sum a list of numbers provided as parameters), but we couldn’t make it work. Looking at the logs, the recursive part worked fine, but the final data just wouldn’t be accessible from the front.

Have you had any success with this specific case ? If anyone has a tip, I’d be grateful to hear it !

Thanks in advance !

[georgecollier]

Probably too much recursion - a workflow that calls a workflow that calls a workflow that calls a workflow to return data to return data to return data to return data isa recipe for disaster!

[S-J]

Thanks for the quick answer @georgecollier !

We did set it up so that there would only be one return data at the last iteration. The WF had 2 parameters : number_list and sum. Whenever it called itself, it would give new parameters such as number_list = number_list minus first item, and sum = sum + number_list first item. We tried it on a 4 items list, and conditionned the return data to run only if number_list count = 0.

Also tried to change the recursive to use “run” instead of “schedule api”, but this time bubble just crashed with a brand new error msg “Request too deep”, so this one is out.
But it doesn’t explain why our first trials (with a basic schedule API recursive) failed.

Do you think we didn’t set up the workflow properly ? Or do you think this method just don’t work with recursive workflows ? If you managed to find a way to return data from backend after a recursive workflow, I’d be happy to hear about it !

[georgecollier]

@S-J

Request too deep”

Yeah this is exactly the error I’d expect…

Why are you using recursive workflows for a sum?!

[S-J]

To test out the method before using it in the real use case. I didn’t want to set up a whole complexe BEWF with several datatypes and many actions if it simply cannot manage recursive.

And this error was the result of one specific try with a specific setup, all the other tries went fine, bubble didn’t crash, except the final data wouldn’t be sent to the front.

[georgecollier]

Try whatever you’re trying to do with backend custom events rather than recursive API workflows…

[S-J]

My use case is to loop a workflow on a list in the backend and then return a result to the front, and custom events cannot trigger themselves. Unless there is a way to make it work that I am unaware of ?