Is API Workflow the best way to Create/Update Things?

My app must have the ability to create new things (Actions in this app) and update them in response to various user actions on any of several pages. When a new Action is created, it must be linked in a many-to-one relationship with a Project thing.

Obviously, it would be best to have the create and update functions defined once and used wherever needed to ensure that referential integrity and consistency of field values can be maintained.

It appears that I can create API workflows for this. Is this a wise thing to do? If not, what is the best method for encapsulating database actions? I certainly don’t want multiple instances of essentially the same code strewn throughout the app.

Somehow, I thought I’d be able to access the Action created in the API Workflow, but I don’t see that it is available.


It is defined as a return value.


1 Like

The data section in the workflow drop-down has a create a new thing option.

Thanks. I’ve used it many, many times. What I’m trying to avoid is duplicating the Create a new thing and related actions everywhere an Action must be created in the app.

1 Like

Hi @laurence, you’re right that API workflows can be really helpful when your creation/edit process involves several steps and linkages.

  • Pros: reduces redundancy because you can trigger the same flow from multiple places, reduces lag on the screen when someone triggers it, because it’s happening on the server side

  • Con: because you send the command to the server, you can’t use the result in the next step in the workflow, and the timing isn’t guaranteed so if the user needs to see the resulting item on their screen it might lag

Another approach we sometimes use is to create a reusable element with a custom workflow that triggers the sequence. You can then put this reusable on multiple pages and trigger its custom workflow from different places. This handles the redundancy issue but not the on-screen lag one.


I use the method you describe in that situation.

1 Like

I tried the reusable element approach at one time but ran into serious performance issues. I may have caused the problem in how I did things. That is, I don’t know that the speed issues were inherent to the reusable element of something else I was doing within the element.

Have you found that one approach is slower than the other?

I’ve used a header’s states for global variables. If I need to navigate to a different paages, I send the vars to the header on the landed page. It can be slow, but some UX frills can make that less painful

We don’t typically notice performance issues with the reusable approach – it should act like anything else that’s done on the page, so perhaps the workflow series itself is just complicated and it’s best to go API workflow.

I’m confused about returning data from the API Workflow.

I used the Return data action.

I assumed that would make the just-created Action thing available to the invoking workflow. But it doesn’t seem to be available, unless there is some parsing or other incantation I need to do.

No doubt I gummed things up in the reusable element. I wrote just about all of it, including nearly 30 custom workflows without testing any of it. As I began testing it, I encountered extremely slow response. Next time around, I’ll take the incremental approach, testing each custom workflow as I go.

If you schedule an API workflow, the step finishes straight away, returning the ID of the schedule (which could be in the future), allowing for a cancel option. The API workflow will run when scheduled, asynchronously of the initiating page workflow. The Return data doesn’t go anywhere useful, possibly showing in the server logs.

If you make the API workflow endpoint accessible externally, you can define it in the API Connector. Calling it via API makes the API workflow synchronous to the page workflow, the calling step waits for the API workflow to complete, and the Return data becomes an API data structure usable in subsequent steps.


Thanks for this description: I’d been wondering if that was what happened (but hadn’t tested it).

Thank you for this explanation. I’ll put this into practice very soon.

This sounds interesting. But can you still call the API workflow this way (through the API Connector) to run on a ‘list of things’? This would be really helpful.

I tried it and it worked! :sun_with_face:

1 Like

Hi @mishav,

Your suggestion to call an API workflow through the API connector (if I understand it correctly) to make it synchronous sound brilliant but I am struggling with actually implementing it in Bubble.

I am trying to create some data via an API workflow that I then want to send to a page and I think it would be perfect for that but I do not manage to have it working properly. Could you elaborate a bit more on the steps required to do that (especially how to create the API in the API creator and make the link with the API workflow)?

@laurence or @davidb2 did you manage to have it work on your side?

Many thanks


I didn’t do any more with this. Hopefully @mishav can point you in the right direction.