API workflows
This section covers API workflows and how to set them up in your application.
Last updated
Was this helpful?
This section covers API workflows and how to set them up in your application.
Last updated
Was this helpful?
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 , 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.
There are several key differences between an API Workflow and a 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 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 users, it still adds to the total workload of your app.
Scheduling an API Workflow is in itself a process that can take a few moments to complete - for simpler workflows it's sometimes 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 workload, 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 on-page workflows can slow down the front-end of your app, but if run in the backend your users will not notice
Using API Workflows 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:
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:
After an API Workflow has been created and set up to be 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.