Yes, exactly. The AI response is a JSON string nested inside the message content field. Bubble treats it as plain text, which is why I couldn’t access the nested list.
For this, you need to parse that JSON. Bubble can’t parse a string that is a JSON coming from OpenAI, so you need to work around this in other ways.
You can create an API workflow called “parse-json”, create a field called json, and simply have it return that in “return data from API” as shown in the screenshot below:
That way, you can configure this API call in the API Connector, where you send the content of the OpenAI LLM response in the “json” field, and Bubble’s response will be the parsed JSON. Then you save that body there in the API Connector’s initialize.
I have to follow the ‘Internal API Bridge’ solution to parse OpenAI’s text response into a JSON object.
My setup:
Backend Workflow: Named parse-json, has a key json_text (type: text) and returns it via ‘Return data from API’ (Plain text).
API Connector: Pointing to https://myapp.bubbleapps.io/version-test/api/1.1/wf/parse-json.
The Issue: I keep getting ‘Status code 400’ or ‘Unexpected token’ when initializing.
If I put quotes in the body {"json_text": "<json_content>"}, it says it expected a string but got an object. If I remove them, it says ‘Unexpected token g’.
here is the value i put: {“groups”: [{“group_name”: “Test Group”, “guests”: [“Jean”, “Marie”]}]}
How should I format the Body and the Value to successfully initialize this call as a JSON object?"
Now my call is ok. however I still have some issue to complete this step
I am unable to select a custom Data Type created via the API Connector when defining a parameter in a Backend Workflow. Although the API call is successfully initialized and saved, the type is missing from the dropdown list in the Backend, even though it is visible in the frontend workflows.
My Configuration:
API Connector: I have a call named JSON Parser Internal that parses a JSON string (returning a group_name [text] and a list of guests [text]).
Usage: I have tested the call as both Action and Data, clicking Reinitialize call and Save after each change.
Frontend Workflow:
Step 2: OpenAI call generating a text response.
Step 3: JSON Parser Internal (Action) transforming that text into an object.
Step 4: Schedule API Workflow on a list. The Type of things is correctly set to JSON Parser Internal (Bubble recognizes it perfectly here).
The Issue (Backend Workflow):
In my API Workflow, I created a parameter named donnees_ia.
When I try to select the Type, I search for JSON Parser Internal but it does not appear in the list (not in search results, nor under the “API Connector” category at the bottom).
I have refreshed the editor (F5) multiple times, but the type remains unavailable in the Backend.
Question: Why does Bubble recognize the API Connector type in the Schedule API Workflow action on a page, but refuse to display it in the parameter definition of the Backend Workflow? Is there a specific trick to force the indexing of this type for backend usage?
This is actually expected behavior in Bubble and not a configuration problem.
Bubble treats data coming from the API Connector as temporary. That’s why it works in frontend workflows (including Schedule API Workflow on a list): the data is only passed between steps and doesn’t become a real, persistent type.
Backend Workflows work differently. They only accept stable types, like text, number, date, yes/no, or database Things. Types created or inferred from the API Connector are not available there, so they won’t show up in the backend parameter dropdown.
Refreshing the editor, reinitializing the call, or switching between Action and Data won’t change this — there’s no workaround to force it.
The usual solution is to pass the API response as raw JSON (text) to the backend and do the parsing or processing there.
Here is the updated English version of the message for your reply to Ricardo. It clearly explains that you followed his instructions but the issue persists.
Subject: API Data Type still missing from Backend Workflow Parameters (following Ricardo’s method)
"Hi Ricardo and everyone,
I’m following up on this because I tried the technique of isolating my JSON parser into a separate API call to force Bubble to recognize the data type, but I am still stuck.
Here is my current setup:
I created a dedicated API call named “AA JSON Parser Internal” in a separate group.
It is set to Use as: Data and Data type: JSON.
Initialization is successful: the fields group_name and guests are correctly detected, and I clicked SAVE.
The Problem: When I go to my Backend Workflow (create_single_group) to set the type for my parameter group_data, the call “AA JSON Parser Internal” simply does not appear in the dropdown list.
The strange part is that this API call is visible and selectable in the workflow actions (Step 1), but it remains completely invisible when trying to select it as a Type for the workflow parameter itself.
I have already tried refreshing the editor, renaming the call to “AA”, and toggling between “Action” and “Data” modes several times.
Has anyone experienced this bug where an API Type is recognized by actions but won’t show up for Workflow Parameters?"
Just to add another option: since the backend only accepts raw text, one approach is to process the JSON directly on the server instead of trying to convert it into a Bubble-compatible format.
If you want to validate your idea, I can give you temporary access to a plugin I developed so you can see this approach working in practice. Just send me a DM.
Thanks for your feedback. You are absolutely right: since the backend prefers raw text, trying to force a custom API Data Type into the parameters seems to be the root of the problem.
Instead of using a plugin, I’m thinking about keeping the group_data parameter as text and using Regex directly in the workflow actions to extract the values (like group_name and guests).
This seems to align with your suggestion of ‘processing the JSON directly’ without the headache of Bubble’s type conversion.
Do you think using :extract with Regex on the server side is a reliable way to handle this, or are there specific edge cases where your plugin approach would be much safer?
Thanks again for pointing me in the right direction!
Regex can work if it’s configured correctly, especially when the JSON structure is very strict and predictable.
The main issue is that it’s quite fragile. A small change in the JSON — formatting, ordering, or nesting — can break the extraction. When that happens, it’s often hard to debug and even harder to detect where it broke.
The bigger concern is reliability: if it breaks for one user, it usually breaks for all users, and from a user perspective the feature just stops working.
For quick tests or internal tools, regex is fine. For user-facing or long-term features, it tends to be risky
You’re absolutely right about the fragility of Regex. Since this is meant to be a reliable feature for users, I’d rather avoid a ‘fragile’ setup that could break with a minor JSON formatting change.
I’d like to take you up on your offer to try your plugin approach. It sounds much safer for long-term reliability. I’ll send you a DM right now to get temporary access. Thanks a lot for your help!
