System hard limits
System hard limits
When creating plugins for Bubble, it's important to be mindful of Bubble's hard system limits. These constraints for plugin development mirror those in general Bubble development. The article below covers this subject:
Article: Hard limits
The API calls tab is where you connect your plugin to external services. An API call can fetch data from a service or trigger an action on the service's end, like sending a message or charging a card. Calls that fetch data are usually GET requests, while calls that perform an action are usually POST requests. API calls work the same whether your plugin targets web, mobile, or both.
Most calls require some form of authentication so the service can identify who's calling. You set that up per collection, alongside the individual calls.
This article covers how to set up a call.
Authentication methods are covered in our API Connector article on authentication.
If you're new to APIs, you may also find our Introduction to APIs and What is a RESTful API articles useful, along with the API Glossary for unfamiliar terms.
Implementing an API connection can differ from one API to the next. Most follow a few common standards, but if you run into trouble, it's worth reaching out to the API provider or asking on the forum.
Setting up a call
API calls are grouped into collections in the left-hand panel. To add a call, select or create a collection, then define the call itself.
Method and URL
Choose the HTTP method (such as GET or POST) from the dropdown, then enter the endpoint URL. To include a dynamic value in the URL, wrap it in square brackets: []. That turns it into a parameter you can fill in later. For example, https://www.test.com/api/[id] makes id a parameter.
You can also click Import cURL to set up a call from a cURL command, which fills in the method, URL, headers, and parameters for you.
Call properties
Property | Description |
Attempt to make the call from the browser | Runs the call from the user's browser rather than through Bubble's servers. Only available on calls that don't require authentication. |
Headers | Add any headers the API requires, such as a content type. Click Add header for each one. |
Parameters | Add parameters the call accepts, including any you defined with square brackets in the URL. Click Add parameter for each one. |
Include errors in response and allow workflow actions to continue | Lets a workflow keep running even if the call returns an error, rather than stopping. The error details are included in the response so you can handle them yourself. |
Capture response headers | Includes the response's headers in the returned data, not just the body. Useful when the information you need is in a header. |
Setting the response
The Response row controls how Bubble treats what the API sends back.
Property | Description |
Use as | Whether the call returns Data (used to retrieve information) or an Action (used to perform an operation in a workflow). |
Data type | The format of the response, such as JSON. |
Once you've filled out the call, click Initialize to run it once. Bubble reads the response to learn the structure of the returned data, so your plugin's users can reference each field. If you can't run the call directly, click Manually enter response to define the structure yourself instead.
If an API call takes longer than 150 seconds to complete, Bubble automatically retries it. This matters for actions like sending emails, where confirmation from the service can take more than 150 seconds to come back. A retry in that situation may result in a duplicate action, such as an extra email being sent.
You can see an example of the implementation of call of the iTunes API here.