API Workflows
This section covers API workflows and how to set them up in your application.
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 HTTP request to your app, this is often described as a webhook. 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 resource. 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.
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
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 |
Setting up workflows that run server-side is useful in several situations:
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.
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.
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 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:
Then you need to use the Schedule API Workflow action to schedule the workflow at the current time or in the future:
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:
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:
Before you can access your workflow from an external system you need to decide what kind of authentication you want to implement:
Finally you can send a request to your application by directing the external app towards the correct API Workflow endpoint:
Last modified 7mo ago