[New Feature] Native JSON parsing is now available in the API Connector

Hi everyone,

My name is Nick, and I’m a product manager on the editor team. I’m excited to announce that JSON parsing in the API Connector is now live.

If you’ve ever connected Bubble to an LLM API and found yourself building a workaround just to get access to the data inside the response, this update is relevant to you.

What changed

Until now, Bubble couldn’t parse nested, stringified, JSON structures, which meant extracting usable fields often required making an API call back into your own app, or piecing together plugins and workflows just to surface what you actually needed. These workarounds could add extra workload consumption on top of the original API call, and if the API’s response structure changed, the workaround had to be updated too.

With this update, the API Connector can now automatically read and understand the full structure of a JSON response (including deeply nested data, arrays, and complex response structures) and make every field directly usable in your app. The data is immediately accessible in workflows, pages, and expressions, without any extra setup.

We also updated the response UI to reflect this. Previously, the response preview would flatten everything into a long list of fields, which made it difficult to understand the shape of the data. Now, responses are displayed in their original structure, making it easier to reference exactly what you need.

What this means for you

This is most impactful if you’re building with LLM APIs. Providers like Anthropic and OpenAI often return structured JSON in their responses, and those fields now come through natively on Bubble.

For example, imagine you’re building a trave companion app that calls an LLM API and gets back a structured list of itinerary items, each with dates, location, notes, and a generated summary, but unfortunately, the API returns all of that info inside one field called content.

Here’s an example of what that response might look like:

Now, you can parse into that as if they had sent the response like this:

That means, days and items are available as lists. You can bind them to repeating groups and reference title, location, etc. as fields on each item, and use summary in a text element, all without any extra steps to set up.

Note on backwards compatibility: Existing API Connector calls are not affected by this change. If you have calls already configured, they will continue to work as before. If you choose to reinitialize those calls, you’ll see the new JSON parsing options and can decide whether or not to apply them. If you do, you will likely need to update any expressions that reference this API call to use the new fields.

Give it a try

We know this feature has been long-awaited, and we’re excited about finally going live with it. If you’ve been holding off on building certain API integrations because of the limitations around JSON parsing, this is a good moment to revisit those builds.

Try it out and let us know how it goes. Looking forward to hearing your feedback!

Nick

Thank you for the update. Testing soon.

This is a great update!

Can you also get a look at the topic related to the new API Connector location? There’s a lot of pending requests :wink:

Wow, can’t wait to test it @nick.carroll . We’ve been waiting for this for 7 years :smiling_face_with_tear:

Great update :star_struck:

Yes

Thank you. A couple of questions:

  1. Am I correct in assuming that the structure of the JSON will be public and available to any client? If so, it would be great if there was a way to split this up into private/public for proprietary purposes.

  2. Does this create an “API type” that can be stored on a field?

Awesome! Now we just need native JSON to datatype and it will open up a whole new way of data management for power users.

That is next up!

Finally its here! Thanks @nick.carroll less workarounds!

I pray every day for this to happen. We’ve never been this close :joy:

Omg! I love you!

This is definitely useful, but can we just have a :parsed as JSON operator? The challenge with the API Connector implementation is that as far as I can tell (and I may be missing something) you need an API call for each possible JSON response. For any serious AI agent built in Bubble, they have multiple tools, all of which need to be parsed. :parsed as JSON would take a text input, and let you select an API JSON type to parse it as. If it can be parsed/is invalid JSON, it would be an empty object.

100%. Even if you don’t use tools, just specifying the API call dynamically is much more efficient than setting it up in the API connector. The API calls I initialize are completely blank, the entire body goes in the actual action’s text. I actually wouldn’t be able to use it in my current setups for this reason.

What will be different with a parsed as json? We will also need a JSON schema for each possible output to use it correctly with Bubble native feature no?

I want this function for sure, but if using API connector,this can be parsed, I don’t see the use of this function with API connector (but with some other payload for sure).

Yeah but I can take an AI tool call text, and use :parsed as JSON to get it to whatever type I want, rather than using a distinct API call for each possible JSON output, which is a maintainability nightmare. Unfortunately I can’t think of any use cases in our current apps that we’ll be able to update to use this new feature :frowning:

Basically, I need to be able to:

  • be given a text input
  • specify a type of JSON object to parse that as

Whether that be a JSON schema I have to define, or an API type, or I provide an example object, I don’t really care, but we’ve got to be able to parse any text into a JSON anywhere regardless of whether it’s in the API Connector or not.

This is a great idea! Has anyone been able to replicate the video example already?

I’m yet to see the checkbox and the “parse as json” options. On version 33, new API entirely, restarted everything

@Viktor are you using arc or ad blockers perhaps?

Please make it possible for the JSON to include an ID that would be used as the unique ID…that way we can create client side a full custom data object and throw it away without cost of WU or save it to DB as a new custom data type record. This will expand functionality for plugins using exposed states as a type of custom data type, so they can create and expose them for subsequent database saves. Would need a new workflow action to complete of create new thing but accepts a complete object rather than individual fields.

Where will that JSON object first be set? How is bubble going to know which objects to list for you to choose from? How will it know what key values to map to object shape properly?

If you’re talking like some generic object as some sort of container, that’s just text. If you want an actual object whose keys are known and values mapped to properly for use in data displays or workflows, you need to first create the object, which we do now in the Ali connector.

I think the ask is not for other way to create objects, but another workflow action to turn a JSON text into the object? What’s the usefulness of that?

likely in a new global setting that’s not the API connector (like a new feature that’s coming out tomorrow…)