[Help] Type Mismatch When Setting Custom State from API Response (Get vs Update Assistance)

Need help
1

Hey everyone :waving_hand:

I’m building an app that connects to a third-party REST API and facing a type mismatch when storing API data in a custom state.

Setup

  • Two API calls in API Connector: Get Assistance and Update Assistance

  • Both return identical JSON, e.g.:

{ "id": 123, "name": "John Doe", "email": "john@example.com", "status": "active" }

Problem

  • Setting a custom state (e.g., state_assistance) using Get Assistance works.

  • Setting the same state with Update Assistance later throws type mismatch, even though both responses have the same structure.

  • I tried creating a Bubble data type (Assistance) to mirror the response, but it still mismatches — likely because Bubble Things include system fields like Created Date, Creator, etc., which aren’t present in the API JSON.

  • Important: I don’t want to create dozens of individual states (state_name, state_email, etc.) — that’s cumbersome and non-scalable.

Goal

  • One unified, scalable approach to hold API response data (from Get or Update) in a single Custom State, without unnecessary DB writes and without creating many per-field states.

Question:
What’s the best and most scalable approach in Bubble to handle this — where multiple API calls return the same JSON structure, but Bubble still objects when setting the same Custom State?

2

A workflow could send the response from API Update Assistance into javascript and back into Bubble unchanged, “re-badging” it as a response from API Get Assistance. Another workflow (or custom event) to set the value to custom state.

Run javascript:

var assistance = properties.param1;
bubble_fn_assistance( assistance );

Javascript to Bubble:

bubble_fn_suffix: assistance

value type: choose Get assistance API response type

A similar-ish example is Examples - Toolbox docs

What do you mean by scalable in this question?

3

Let me explain the issue in detail:

  1. On page load, I call get_assistance and set a state called test_state, which is of the type returned by get_assistance. I use test_state on my page, but when I call another API, update_assistance, and try to set the same state, an error occurs. This happens because Bubble interprets it as a different type, “Update Assistance,” so this approach doesn’t work.

  2. I then created a custom data type called Assistance in the Bubble database, mirroring the structure of the object returned by the API. However, Bubble automatically adds extra fields such as Creator (type: User), Slug (type: text), Created Date, and Modified Date (type: date). Because of these extra fields, there’s a type mismatch, and I cannot set test_state of type Assistance directly from my API response.

  3. I considered using the Toolbox plugin to map the API response to the Assistance data type using JavaScript, but it didn’t work. The main issue is the Creator field on the Assistance data type—I couldn’t find a way to populate it via JavaScript in Toolbox, so this approach also seems unfeasible.

  4. The only solution that works reliably is to use separate states for each property, such as model_name, assistance_id, and other fields (over 10 properties), and set them individually. However, this approach is inefficient and cumbersome.

I’m looking for a more efficient solution in Bubble, ideally a dynamic state type that can adapt to API responses without requiring a fixed structure.

4

You are right, Bubble doesn’t have a shared API response. Some workarounds …

a) The JS rebadging I outlined earlier, can also rebadge to an arbitrary API response with manual definition.

b) Send both responses to the app’s API workflow and return a standard response of your own design from backend.

c) Configure the API calls to respond in JSON text. This means having to parse the JSON later, which can be a pain, depending on what needs doing.

d) The API call can be done in JS, handling the response can be like a) or c)

You are correct, the database requires a “create thing” or equivalent, with setting each field.

This made me laugh: I remember trying to do the same thing some years ago. Bubble database is stubborn and refuses to acknowledge imposter data!

If you share more of the intended functionality, more people can contribute ideas and workarounds :slight_smile:

1 Like
5

You could use the Data Jedi Plugin to do this.

1 Like
7

Now I just created new data from the upcoming api post call on the Bubble database and have to update each time I update the external data
But if someone deletes any data from the external database, it will be a mess because bubble data will remain, but I will not delete anything outside of bubble :slightly_smiling_face:

8

You could easily fix that by doing the GET after you did Update. Yes it will cost you a little bit more.

For Bubble, this create two different Data structure even if they are this same (often requested… but not implemented).

Another option could be to use Backend WF + API Connector. Again, this will cost you more, but you will be able to do two call but return one data from both call. So this endpoint will be called using API connector and return data will always be the same even if you don’t do the same action in the backend WF

2 Likes