Looks cool: thanks
Really good.
Awesome ! Didn’t check it out yet but will do soon.
Really nice update! Finally! 
Some idea:
- Rename “Data type” to “Response data type”. Often, user think this is related to request while it’s not the case
- Remove Use as and automatically make all call available in data AND action. I see some users that create two call because they want to use them in both option (even if, in most case, GET should be used as DATA while PUT, POST,DELETE… should be used as action. However, POST can often be used in a search request)
- Already on the ideaboard: (Already have a lot related to API…)
- Add application/x-www-form-urlencoded to Body type in API Connector
- Do not Follow redirect option in API Connector
- Add Development fields for API Connector when selecting Basic auth
- HEAD request in API Connector
- Dynamic parameters in all Auth type
- Add oauth1 as possible authentication in API Connector (often used in AWS)
In Workflow tab, we have + icon to add WF in a folder. But also three … dots to have more option like deleting or renaming the folder. This should also be available in collection left tab.
Good catch! This is a bug, looks like the team will have a fix up for this soon.
Thank you for the feedback! Logging for consideration
glad you are getting value out of this as well… always felt wrong having to re-initialize a call just to see the response again
Great flag, noting this down for consideration
Legend @nick.carroll 
looks great.
@nick.carroll I’ve noticed a couple of issues.
- When initializing a new api call from the new tab, the data type doesn’t become available to the data sources of the application. I attempted to refresh the browser twice and it still did not show up. I then went to API connector plugin to reinitialize the new api call, and it still did not show up in list of datasources. Only after refreshing the browser again did it finally show up…so seems initializing new calls in the tab do not allow the new ‘data type’ to become available as a source in list of datasources when setting up a repeating group for example.
- When I create a new api call in the new tab, by having to click the plus icon at the top of the list, the new call is randomly place, or perhaps placed alphabetically based on the default value of ‘api call’…then when renaming it, the ordering doesn’t change position into an alphabetical ordering, it just stays in same location. Additionally, in the API connector plugin that same new api call is at the bottom of the list as is the expected and long standing behavior. Only once I reinitialized in API connector and refreshed the browser did the new api tab show the api call in the same location (at the bottom of all calls).
Suggestions - Either make the new tab automatically add new calls to bottom of list, or get the api connector to sync positioning with the new tab so we can easily see all calls in the same order. Additionally, when initializing a new call in the new tab, it should immediately be made available as a data type in the datasource list of the app without needing to initialize in the api connector and refreshing browser. Also, the name of the api call in the new tab should not only be accessible via the left side bar as today, it should be in the main view as the api connector plugin does so as to avoid cognitive overload of users, losing the new call through forgetting to manually rename it on left side and ensure the new data type is properly logged as a datasource for the app (I imagine the name we give it is somehow connected to the ID bubble assigns in order to make it a datasource of the app).
Looks nice!
A couple of other updates which are needed:
- Let us natively define API Object Types without having to do a weird Get call to our own backend workflow.
- Let us parse OpenAI responses natively without having to use a plugin or calling our own public backend workflow.
Edit:
Minor UI improvement would be to make the inputs bigger (overflow) instead of cutting off when using longer strings. Right now I have to copy it into notepad, edit it, then put it back in whenever that’s the case.
Edit #2:
Another thing I noticed is that navigating the different sections might be confusing to new users due to a lack of hierarchy. The text all seems uniform with regard to size and weight. Just a bit more separation between the areas would be nice.
Great update, looking forward to trying out this new version!
Congrats on the update, Nick! The new location and interface for the API Connector are great improvements.
A feature that would be truly game-changing: an AI that reads API documentation and automatically configures the calls in Bubble.
How it would work:
-
User pastes the documentation link (e.g., OpenAI docs, Stripe, etc.)
-
AI analyzes endpoints, parameters, headers, and authentication
-
Automatically generates the complete configuration in the API Connector
Why this matters:
-
Many Bubble users choose no-code precisely because they don’t have a technical background in concepts like REST, OAuth, headers, etc.
-
Manually configuring APIs is still a significant barrier for beginners
-
This would drastically reduce integration time and configuration errors
You already have cURL import, which is excellent. This would be the natural evolution: instead of asking ChatGPT to generate the cURL and then pasting it into Bubble, the platform itself would do it directly from the official documentation.
This would reinforce Bubble’s position as a truly accessible tool for non-developers.
when i click on one of these i have to re-initialize, would be great if this can be changed without re-initialize.
@nick.carroll The use of the grey box and text about re-initialize to change string to actual values is confusing
It is very prominently placed and always there, making me constantly think I did something wrong, or didn’t initialize all values. It seems to be just ‘helper text’ to provide some extra details…I’d suggest removing it and placing it at the top of the initialization popup.
Also, a major issue, is this error/bug below
From the new tab, I pressed the blue reinitialize button on far right that is in the first screen shot shared in this post. The result is the screen shot above. This is for an API Object that I am using the API connector to create a ‘data type’ in the app for.
The issue is the same in the API connector, HOWEVER, in the api connector plugin we have two choices prominently placed as in the screen shot below, that is button to re-initialize or the text button to manually enter response.
In the screen shot above you can see the button to re-initialize is not available because the URL is empty as it should be for this approach to use of an API Object.
The way the api tab looks for this type of API object with no URL is in the screen shot below
As you can see the blue re-initialize button is now red (would be better to be greyed out like the api connector plugin) and when hovered it shows a tooltip indicating the call has been changed, but it has not been, it is just that the api connector plugin and api tab are not in sync and the call was re-initialzed manually from the api connector plugin in order to remove the URL (more on that later).
There is also a clear missing ‘manually enter api response’ button as was pointed out by @adamhholmes originally and @georgecollier pointed it out for where it is on a new api call, but the issue exists for an existing api call.
In terms of the URL or name, in the plugin version we had a nice easy way of adding name when creating a new call as in screen shot above. Prominently placed input directly above the URL…made it simple to add/edit and see when reviewing the call.
Now in the new tab, we do not have any input to add the new name, we have to instead use the left side menu, which is not intuitive, and since a new call has a default value of API Call, if we forget, or do not know to change the name on left side menu, we may end up with a lot of API Call, and then need to spend the time trying to review each and changing the names. It also makes it harder to keep on top of mind (because it is missing visually from sight) when reviewing the call what the name is. It would be better to have it on the main view above the URL input. The new view in screen shot below is missing that key functionality and detail of the name directly where a users attention is when creating api calls, until you become overly eager and investigative to click on what looks like text to find out it is actually an input to change the name.
In understand UI designers are wanting to impress, but in terms of UX it is failing to have what actual is an input look just like text, and small enough that is not prominent as what I personally would expect, since for me personally, the name is kind of like a ‘title’ and should be large text, but in this case, it is also an input area, so should look like an input.
Lastly, a suggestion of a feature related to API. If we can get API objects, be available as parameters for backend workflows that would be great. Currently it is not possible to have a backend workflow with parameters that are the API Objects (the data source created on initialization). Some users have expressed confusion of how to use API Objects effectively in their backend workflows for some features they created for use with AI. This would make it easier for users to understand how to work with API data better in their apps, but also it is just kind of the last and only area of the entire platform where API objects are not treated as every other data type.
We have Option Sets
We have Custom Data Types
and we have basic types
BUT We do NOT have Plugin Types, or rather API Types (by the way, now that api connector plugin is no longer needed, will these types of data be name appropriately as API Types, so we have API Types, Plugin Types, Basic Types, Data Types and Option Sets?)
We do have them in backend already for custom events, and everywhere else, just not backend workflow parameters.
You do not need to do any weird get call to your own backend workflow to define API Object Types…what are you even using them in the app for if that is how you are creating them?
For existing API calls you can just edit the raw response directly.
That’s true - you don’t have to make an API call to your own backend to use API objects (you can create them directly) but it’s still not ‘natively supported’ (which it should be - although there shouldn’t be any need to involve the API connector at all for such a basic, fundamental need).
Thank you all for the feedback so far. Keep it coming. The team is keeping tabs on the thread
Amen! When setting up API calls it would be so useful to have an interface that’s actually designed for API logs. The server logs make it so difficult, and non-successful API calls don’t even show up! This makes it incredibly difficult to troubleshoot. @nick.carroll
I always check the boxes to continue with errors and show headers. After every action api call, I set up an action that conditionally creates an entry in a data type I call api fails. Saving the error message and other details to easily track and see any issues with api call actions.