Oh, okay. So take JSON a user manual enters as text and turn it into a Bubble custom data type entry.
Is the intention that it will output a non-stored equivalent that can be used in data sources or existing data sets client side before running an action that will save it to the database? Or will it just be an action that is taking JSON and immediately creating the bubble custom data type things in the database, the output of the action then being the stored in database list of things?
The purpose as I see it is being able to use JSON from other applications in a way that feels native to Bubble. For example instead of using dot notation like object.field you can use the expression editor like you would with a Bubble datatype.
There are times you don’t need to convert a JSON object into a Bubble DT because all you want is to display values on the screen from another application OR you want to only take some of the values (like transaction data where you only need a couple field.
Love all the comments and contributions!
I agree that turning any text as formatting it as JSON so that we can use the expression editor would be great!
AFAIK → it’s not a Bubble-only limitation that JSON needs to be “defined” somewhere.
So, similar to the API example, I think even if we created a new place to declare JSON objects, you’d still need to do some set up. It won’t be as simple as taking any arbitrary text and parsing it as JSON without defining the structure first.
Would other application be like an API call, or is there some other anticipated use case where data from another application is brought into the bubble app? I’m just thinking it sounds like we already have the functionality via API connector if the data is from another application.
Yes, if you make the api call from the api connector then you are set!
For me, sometimes you get JSON as a string in the response of an API call, and this is a simple way of formatting it.
Also, in the past I have saved raw JSON into text fields for later use or to fetch something. This helps me do that.
You know that you can save the whole result of a parsed call from API connector into a field of the type of that call?
Honestly, I don’t see a lot of case to use a JSON as a text…
usually debugging (:
it’s the response in time as it was. If you re-initialize your call and add/remove fields then that will be reflected in the saved api response type.
I am not able to pass the newly created psudo data type (The one that API returns) to another backend workflow.
I am able to use it in the frontend as a data source. But when I am trying to pass it to the backend workflow to use this data and create an instance of actual data type that I have in DB using this data, I am not able to pass it. I am having to pass the json text again and re-parse it. And if it is a list, then having to re-parse for all the items in the list by passing the list index.
Is this the way it has to be done or am I missing something?
Bubble currently does not allow API Objects to be passed through backend workflows as parameters of the backend workflow - this should change.
To see Bubble fully support the third and fourth data types of API and Plugin Objects Upvote the Idea HERE
In the meantime you can use custom events in the backend workflows which do support API Objects as parameters.
Thanks @boston85719
For now I used custom event in frontend itself. Backend workflows were getting messy.
Your ideaboard link was not working. I upvoted another idea which seemed similar to me.
In case anybody else can’t open link (seems to work for me)…this is proper idea to upvote for the functionality necessary
Totally missed this @brad.h - feel free to ping me again next time 
did you build out the survey? You can do all that with the bubble datatypes.
