Adding calls
After authentication is set up, you can add as many calls as you need to the API provider.
Last updated
Was this helpful?
After authentication is set up, you can add as many calls as you need to the API provider.
Last updated
Was this helpful?
This core reference entry is suited for advanced-level builders.
Choose a name for this call. It must be unique because no two API calls can have the same name.
Select from Data or Action to determine how this call will be used in Bubble. Data calls appear in the 'Get data from an external API' dropdown menu and Action calls appear in the Plugins section of the Actions dropdown menu.
This deletes the API call.
Warning: Deleting an API call is permanent and cannot be undone.
This is the . The most common are GET, POST, PUT, PATCH, and DELETE.
This is the call's URL. It is not client safe, meaning the value is not sent to the user's browser when the call is made.
This is the call's body. It is client safe, meaning values are sent to the user's browser when the call is made.
Click to add and configure a new HTTP header to this specific call. Check the Private box to stop the information in the header to be visible client-side. Check the Optional box to set up this specific key to be optional.
Select here the body type of the request. Most requests will send a JSON body, but for more advanced usage (such as uploading a file), you can use a Form-data or Raw body.
Click to add and configure a new call parameter. Parameters are not sent to the client by default, but they will be if you enable the Client-safe checkbox.
Default values for an API connector call (or plugin) behave differently if they are optional or mandatory. Optional default values are placeholders that aren't passed to a call unless they're changed to something else in the app. Mandatory default values are actual default values.
Check this box to prevent a parameter default value used for initialization from being sent to the client or workflow inputs.
Check this box to handle API call response errors yourself. When this box is checked, Bubble will allow workflows or actions to continue when an api call error is returned and expose the error object for use in a dynamic expression. There are 4 parameters that are available as a part of the error object: error's status code (number), error's status message (text), error's body (text), and error's has returned error (yes/no).
When the parameters are detected from an initialization request, you can include the request headers in the detected data if some important data is in them.
Some API calls in the API Connector can run directly from the user's browser instead of Bubble's servers. This can improve performance and avoid shared rate limits imposed by some external APIs.
When this is available
This option appears as a checkbox in the API Connector, but only when:
The call has no headers
All parameters are private
There are no shared headers or parameters
If these conditions aren’t met, the checkbox won’t appear and the call will run through Bubble as usual.
What to know
Only data calls can use this feature — actions and initialization still run through Bubble.
Useful for public or read-only APIs.
Each user's browser sends the request, reducing server load and potential rate limit issues.
Check this box to allow this API call to run directly from the browser, rather than Bubble's server.
The biggest benefit of using this option, on top of performance, is that your API call will not count against API call quotas across all of Bubble, lessening the risk of accidental rate limiting by a 3rd party API.
Note: Due to the nature of this type of client-side (from the browser) API call, it will only be sent from the browser if it doesn't require interaction with the server. For example, using the API call response as a data source.
If this option is selected, but the API call is included in a workflow that involves the server (i.e. making changes to a Data type), the API will revert to being sent from the server.
Whenever an API call is made from the browser, information related to that call can be intercepted on the client side. That means you should be cautious exposing sensitive information (e.g. API keys) in these calls. If you are unsure of the potential risk of sending data to the browser we recommend not activating this setting.
When initializing a call, you should use only sample or non-sensitive data in the parameters. Any data entered during this step becomes part of the API schema, which is included in your app’s source code and could potentially be accessed by others.
Every call needs to be initialized before it can be used in your app. Initialization is done for two reasons:
To confirm that the call was successful
Bubble uses the response to recognize the data being returned by the server
Take caution when utilizing initialization API calls as they may produce actual outcomes, including the modification of live data. Be mindful of what kind of results the initial call may produce prior to executing it.
This option will only available in certain situations. More specifically, this option is only available for public API calls ( is set to None) with no or private . In addition, the call must be used as a . Support for Use as Action is coming soon.
To initialize an API call with mandatory parameters and no obvious default, you can set a default as an example, click to “Initialize,” then unset the default or select .