API Workflows

This section covers API workflows and how to set them up in your application.

Help us improve this article

This article is part of a significant update to the Bubble manual and your feedback is critical to our efforts to continuously enhance our written documentation. We would greatly appreciate if you could take a moment to let us know your thoughts on the quality of it. Thank you for your support! Give feedback on this article

API workflows are server-side workflows that you can schedule/trigger in your application and/or expose to be triggered from an external application or system through an API request.

They run independently of any page, which means they can be executed without anyone visiting your app. By making an API request to the server that hosts your Bubble app, you can create things, sign users up and send emails – anything you can do with a regular workflow.

Whenever an event occurs in an external app and the application sends an to your app, this is often described as a . This allows you to start a process in your application, such as sending a welcome email or adding the user to a newsletter list.

Just like the data API, these requests need to be pointed towards a specific . Bubble automatically creates a URL for each API workflow that you choose to expose. It follows then, that these too are incoming requests – they are coming into your app from somewhere else.

Activating and accessing the backend workflow editor

API Workflows are edited in the section of the Bubble editor called Backend workflows. To activate and access the backend workflow editor, follow the steps described in the article below: Article: Activating and accessing the Workflow API

API Workflows versus regular workflows

There are several key differences between an API Workflow and a regular Workflow:

Action	API Workflow	Regular workflow
Can be triggered from an external application	Yes	No
Will continue running even if the page is closed	Yes	No
Can schedule itself to loop	Yes	No
Can be scheduled to run in the future	Yes, and will run even if the page is closed	Yes, but page must remain open
Can override Privacy Rules	Yes	No
Are executed 100% server-side	Yes	No

Using Server-side workflows

Setting up workflows that run server-side is useful in several situations:

Security

Since the workflow is executed away from the page and user, it’s more secure. One of the main principles of web development is that any kind of process that is performed on the page can technically be intercepted by a savvy user, whereas an action happening on the server can be kept securely hidden away from prying eyes. This is not to say that all workflows triggered on a page are insecure, only that the user of the device may be able to see what’s going on. In most cases this is not a problem, but in some corner cases you should be mindful of where the process takes place.

Let’s say for example that you want to generate a random string of text to send to the user as an extra means of authentication. If you generate that code in a workflow on the page that the user is looking at, the user might be able to see the string that has been generated and circumvent the security measure. This string should be generated and emailed in a backend workflow, since the user can’t see what’s going on on the server.

Performance

API Workflows technically spend the same amount of server capacity as a regular Workflow, but you can still use it to your advantage to make your app seem more performant to your Users. Since any action that takes place on the server does not cause any performance degradation on a Users page, you can move complex workflows to the server to keep your pages lightweight and its code base minimal.

Keep in mind the following as you plan for performance:

• While an API Workflow doesn't create noticeable slowdown for one specific User, it still consumes your app's total capacity (which can potentially cause slowdown for all Users if maxed out)

• Scheduling an API Workflow is in itself a process that can take a few moments to complete - for simpler workflows it's often quicker to simply complete the actions in the page Workflow.

Everything that you add to a page (elements, workflows and conditions) will add to the total size of the page that the browser has to download. By moving parts of it to the backend, you can keep your page as lightweight as possible. Keep in mind that API Workflows also spend your app's capacity, so moving workflows into the backend only affects the loading time and size of the page.

Bulk operations

API workflows are also where you can set up heavier workloads where you need to make changes to a high volume of data. There are a few reasons for why it makes sense to move processes to the backend:

• Processes running in the backend will continue to run until they are finished, whereas on-page workflows will stop running if the user closes their browser

• Backend workflows can schedule themselves, meaning that you can loop them. This is useful when you need to process a list of database things

• Complex workflows can slow down the front-end of your app, but if run in the backend your users will not notice

Even though backend workflows run independently of the page and are not visibly causing slowdowns, you should be careful when running complex processes as they can still max out your app’s capacity. Keep an eye on your capacity charts when you run bulk operations.

Using API Workflows internally

Using API Workflows internally is done in two steps. First you need to Create the API Workflow, and then you need to use the Schedule API Workflow action to schedule or trigger it. The two articles below describe both parts of the process.

First you will need to create the API Workflow that you want to trigger/schedule:

Creating API Workflows

Then you need to use the Schedule API Workflow action to schedule the workflow at the current time or in the future:

Scheduling API Workflows

If you want to run a sequential loop of workflows or schedule it to run at a given interval you can also consider using recursive workflows:

Recursive API Workflows

Exposing API Workflows for external use

After an API Workflow has been created and set up to be exposed as a public API Workflow you can trigger it from an external application by use of an API request. The articles below explain how to create API Workflows, as well as how to authenticate with the Bubble API.

First you will need to create the API Workflow you want to be able to trigger:

Creating API Workflows

Before you can access your workflow from an external system you need to decide what kind of authentication you want to implement:

Authentication

Finally you can send a request to your application by directing the external app towards the correct API Workflow endpoint:

Workflow API endpoints