API workflows
This section covers API workflows and how to set them up in your application.
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.
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 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.
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 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 internally
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:
pageCreating API workflowsThen you need to use the Schedule API Workflow action to schedule the workflow at the current time or in the future:
pageScheduling API workflowsIf 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:
pageRecursive API workflowsExposing 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:
pageCreating API workflowsBefore you can access your workflow from an external system you need to decide what kind of authentication you want to implement:
pageAuthenticationFinally you can send a request to your application by directing the external app towards the correct API Workflow endpoint:
pageWorkflow API endpointsLast updated