Huge thanks to you and the editor team for shipping this. It’s going to save a ton of time and headache! 
Hi Nick! Kind of. I use the browser Brave, which does block ads natively. I just noticed the options on Chrome. Thank you for the attention!
Oh you tease you… Will we finally have a proper state manager?
Native CSS and Javascript actions/events will be nice too. Maybe a function manager. Bubble needs native code integration to become a complete full stack solution. I’ve always viewed Bubble as a high level language akin to React, Vue etc. Maybe one step higher abstraction. So code should be a natural part of Bubble.
@mishav Toolbox’s implementation of Javascript integration, espcially the “Expression” element, is a good stepping off point to how native code integration can look like outside of plugins. Sometimes you just need to run some quick code. Native integration means Bubble can safely scope code during runtime.
With AI code is now “cheap”, it takes a minute to ask AI to build a bunch of functions.
I’m seeing a possible issue with the new Native JSON Parsing feature.
I’m using OpenAI’s Responses API with a JSON schema response.
The API initializes successfully in the API Connector, and the request also succeeds in OpenAI’s logs with valid structured output.
However, when the call is executed (from either a frontend or backend workflow), Bubble throws:
“Workflow error - Issue with the call [API Name]. Please initialize it again.”
I’ve already tried:
- Re-initializing the API
- Creating a completely new API call
- Testing from both frontend and backend workflows
Has anyone successfully used Native JSON Parsing with OpenAI Responses API and structured outputs?
Happy to provide more details if helpful.
I also tested a minimal Responses API call:
{
“model”: “gpt-4.1”,
“input”: “Say hello”
}
OpenAI logs show the request completed successfully and returned a normal response.
However, Bubble still throws the same workflow error:
“Workflow error - Issue with the call Test. Please initialize it again.”
So this does not seem specific to JSON schema / structured outputs. It looks like Bubble is sending the request successfully, but failing when handling the response from the Responses API.
I found something important.
All of my existing OpenAI Responses API calls continue to work.
However, if I reinitialize an existing API call, it immediately starts failing with:
“Please initialize it again”
This seems directly related to the new parsing behavior introduced after reinitialization.
So the issue is not with OpenAI itself, because the exact same API call works before reinitialization and fails only after reinitialization.
Hi Bubble team,
I think I ran into a breaking issue after reinitializing an existing API Connector call with the new native JSON parsing feature.
Before reinitializing, Bubble exposed some nested response fields as flattened fields, so I could select something like:
Result of step X’s body’s detected_company name
After reinitializing, Bubble now exposes the same data as a nested object. So instead of selecting the field directly, I now have to select:
Result of step X’s body → detected_company → name
This changed the field paths across my app and broke many existing workflow expressions. I now have 169 issues from a single API call reinitialization.
Is there any way to keep the previous parsed structure, disable the new native JSON parsing for an existing call, or safely add a new response field without breaking all existing references?
This makes reinitializing central production API calls risky unless there is a way to preserve or migrate the old schema.
Yes, you should be able to optionally choose to not parse a nested object. Mind sharing a screenshot of the shape of your response so I can confirm?
Thanks for flagging, we will dig into it asap. In the mean time, can you please file a bug report?
@nick.carroll We are encountering the same issue
Thanks. I’ve submitted a bug report and provided the requested details. I’ll share any updates here if I learn more.
Your response is a JSON object, not a string that is like a JSON object
Got it, but the issue is precisely with real JSON objects. Before the new native JSON parsing, Bubble exposed these fields in a flatter way, and after re-initializing the call, the same JSON response is now parsed as nested objects.
So existing references broke because fields that used to be selected directly now require going through each nested level.
Is there a way to keep the previous parsing behavior for real JSON objects, or to disable native nested parsing for this API response?
I don’t think this is the case, and is something unrelated? The change to the ‘nesting’ is just UI.
@paul.weill previous behavior with nesting vs flattened objects was determined by the structure of JSON used in initializing the object, not a default feature of bubble to flatten objects.
I have not tried since new feature released so can not comment if any change actually took place, but in past I could initialize an object so everything was flattened off top level key or deeply nested to create multiple new objects from just one initialization.
For example, how I structured my json determined if my contact object created another object called client address or just one object of client.
I always preferred to use nested structure to get multiple object types on one initialization because they named such they were determined related, but I also had plugins of mine that allowed for deep nested functionality. If not using a plugin capable of deep nesting, flattening keys was most developers approach.
I wonder if there is any change now, if that change just is bubble forcing nested objects even if attempting to use a json structure during initialization that would previously have flattened keys.
What @paul.weill is describing is the exact same thing we are seeing.
Basically, after a re-initialization of an API, the flattend API structure is become a nested json body, forcing a remapping of every condition / usage of those values on the UI.
I don’t think it break the API call during run-time when previewing the app (needs more testing), but the editor is throwing mapping errors for every place it it used - forcing a remapping.
Really hoping this is not a forced change.
Edit:
To be more precise, in the example screenshot that you have shared, previously the mapping in the editor for the brief would be body brief(flattened) wherever we wanted to use it, but now, it needs to be body > brief (one level nested - first body, then brief). Doing this for all response fields effectively is causing 100s of mapping errors.
I’m with @georgecollier . We need this desperately. While you can make a list of objects, I often need a list of simple texts that also require a schema (like order, date, etc.). Instead of being able to use a nice schema, we are stuck patching together split by and regex. It all works, but it makes it hard to develop crisp interactions when the basics are so cumbersome.
Hi everyone, appreciate all of the feedback. Addressing a few points brought up above:
This is on the roadmap, and we’ve already done some thinking through how the shape will be defined. Stay tuned for more updates, we’ll likely release this to a smaller group of users for testing since the use cases can get complex.
Noting this feature request to be included in follow-on work
We are addressing this bug
For the most part, retaining the shape of the response upon re-initialization is expected behavior for json objects in a response. When we detect stringified json in the response, which we used to treat as text, we allow you to optionally keep it as text or continue parsing to get at the sub fields. Now, the implication of this is that it may involve re-mapping fields in the UI or workflow if you re-initialize the call. Question to those impacted - if it was relatively straightforward to re-map, is keeping the nested shape of a response desirable? or is it still better to have the option of keeping parts of the response flattened?
Thanks, I guess the global tab becomes a nice home for ‘define a JSON structure’!