The cons of using API objects, do you agree?

[randomanon]

@boston85719

schedule backend workflows action doesn’t accept api objects as parameters

This is a pretty big deal.

@DjackLowCode

I’ll give a concrete example from a learning app which analyzes a users grammar:

“Hey their, I’d like to have made a reservation”

"Fixes":[{"issue":"their","fix":"should be 'there'"},{"issue":"have made","fix":"should be 'make'"}]

Here we have structured data that can be parsed and useful in the app, but wouldn’t make sense as individual DB rows.

Would your calculus change if you had to edit these further? For example, say you could “mark as complete.”

Also, you could process these as two separate lists in the same order. A field that is a list of Issues and another field that is a list of fixes. Modern LLMs are very good at this.

[boston85719]

@georgecollier

Yeah, but then you’d likely be making an API call to your own backend, which has latency and WU (or on dedicated servers, contributes to high server CPU if used regularly). So most of the time it’s more hassle than it’s worth

No, sometimes it is worth a bit of extra effort to get lower costs and expanded functionality possibilities. But as this discussion is focused from the beginning on a more whole system view of when to use or not use API Objects, you may come to the conclusion when juggling the different pros and cons that for you the latency is more of a con than the probably cost savings and expanded functionalities in other areas of the app for that particular type of data.

@DjackLowCode

“Hey their, I’d like to have made a reservation”

"Fixes":[{"issue":"their","fix":"should be 'there'"},{"issue":"have made","fix":"should be 'make'"}]

Here we have structured data that can be parsed and useful in the app, but wouldn’t make sense as individual DB rows.

And one api object can have keys like ‘original sentence’, ‘Fixes’, ‘fixed sentence’, ‘explanation’ and whatever else would be super useful for a learning app.

@georgecollier

Of course, arbitrary example

Keep in mind the concept of how to think logically about when to use or not use API Objects or anything else in bubble for that manner is based on arbitrary examples for which the developer is having the juggle the pros and cons and think logically about whether the pros outweigh the cons.

But, you can do anything with API Object fields as you could with database fields

@georgecollier

If a client asks you to implement those, you’re gonna have a big old refactor. When you could just Schedule API workflow on the list of results to create them and tie them to the user’s message, and it’s created for you.

Ahh, you miss a major point about API Objects, they are faster to manipulate in bulk, so no need for schedule api workflow on list, it is a single bulk manipulation that takes less time and considerably less WUs than a schedule api worklfow on a list setup…so no refractor unless the developer met with the task doesn’t understand how to work with API Objects, which is same as if the developer doesn’t understand how to work with APIs generally like an API for an external DB.

@DjackLowCode

This is where it comes down to “it depends” and foreseeing functionality that may be required in future and what the actual use is

Yes, 100% the way a good developer needs to think about how to use API Objects. This point should not get lost in what if this scenario or what if this scenario hypotheticals to steer the conversation in one direction.

Everybody should understand that API Objects and a Hybrid Data Structure approach is a very powerful tool in the toolbelt for Bubble developers and they should get familiar and comfortable using them.

@randomanon

@boston85719

schedule backend workflows action doesn’t accept api objects as parameters

This is a pretty big deal.

Just run the api call to your backend workflow and send the JSON of the API objects as the payload.

@randomanon

Would your calculus change if you had to edit these further? For example, say you could “mark as complete.”

For me no, because I know it is a simple setup to implement

@randomanon

Also, you could process these as two separate lists in the same order. A field that is a list of Issues and another field that is a list of fixes. Modern LLMs are very good at this.

The way I read that structured data is that the LLM was fed one sentence, and it produced that structured data as a result of it’s analysis of the sentence to provide the fixes and issues of the sentence…I do not read that has what is being fed to the LLM because why would the LLM need that structured breakdown?

[randomanon]

@boston85719

I do not read that has what is being fed to the LLM because why would the LLM need that structured breakdown?

I’m saying the LLM can parse that as two arrays where the indexes correspond and you can in turn use that to create two list fields rather than a single list of API objects.

[boston85719]

Yes, JSON can be manipulated in a lot of ways.

[DjackLowCode]

@boston85719

because schedule backend workflows action doesn’t accept api objects as parameters

Yup a definite limitation, however if you can get the API object to the backend (saved to a thing or as text), you can pass this to backend custom events.

@randomanon another interesting tidbit regarding flexibility with document orientated programming in this case you can setup a full data model, and pass only relevant fields that bubble will still accept. For example:

{ "requestId": "req_9f3c2a1b", "status": "success", "timestamp": "2026-01-08T09:58:12Z", "data": { "id": "obj_123456", "type": "example_resource", "attributes": { "name": "Sample Item", "description": "This is a dummy API object used for testing.", "isActive": true, "createdAt": "2026-01-01T12:00:00Z", "updatedAt": "2026-01-07T18:30:00Z" }, "relationships": { "owner": { "id": "usr_7890", "type": "user" } } }, "meta": { "version": "1.0", "environment": "sandbox" }, "error": null }

You can pass just {"status":"success"} and it will be accepted.

[boston85719]

To see Bubble fully support the third and fourth data types of API and Plugin Objects Upvote the Idea HERE

[boston85719]

@georgecollier

then it becomes tricky to deal with API Objects without server actions that are slow and cost WU

This is not true…yes, if using any backend server side action, WUs are incurred, but some plugin server side actions built for purpose of API Objects are cheaper in WUs, and therefore faster, than bubble server side actions like ‘create new thing’. You can watch this video to verify.

@georgecollier

Additionally, storing API objects on a data type promotes heavy tables. Bubble scales well with long tables, but wide tables that store a lot of data do not as they get throttled by DB disk. Of course, case by case basis, but as a general principle, avoid storing huge things on a database field.

Definitely a case by case basis…right now testing simply an api object as a field rather than a related custom data type as a field, the API object is winning every metric for retrieving and displaying the data. Less server work, faster response times and faster to paint on client device.

@georgecollier

server side plugin actions are inherently slow, and manipulating the contents of API objects requires a server plugin action of some kind

again not true. The fact that video demonstrates clearly less WUs for the server side action to process the JSON into the api object compared to the create a new thing for custom data type, is indicative of the fact that the plugin action is faster, since WUs are derived from how much computing resources used to execute an action.

@randomanon you should explore API objects as they are powerful, and in many cases, more performant and cheaper and therefore more scalable than custom data types…again this is case by case basis and the developer needs to understand how to think through scenarios to come up with the best approach for their use case.