The cons of using API objects, do you agree?

Questions
1

I asked GPT 5.2 Pro about this and am curious as to whether this is a hallucination or real. I’m currently deciding between using a plugin to parse JSON into fields or saving the whole thing into an API object.

But: those API objects are not first-class Bubble Things.

They don’t show up in App Data, and you can’t Do a search for... them, create them as their own Things, or make changes to an individual one. You can only access them through the parent field that’s storing the blob. Bubble forum users describe them as “not saveable nor searchable… like a primitive,” and not available in “Create a new thing / Make changes to thing” workflows. (Bubble)

That distinction drives almost all of the pros/cons.

Cons / gotchas (these are the big ones)

1) You can’t search/filter/query it server-side like real data

This is the killer limitation:

  • You can’t “Search for all results where output.score > 0.8”

  • You can’t build indexes

  • You can’t run privacy rules per nested field

  • You can’t update one nested value; you replace the whole blob

Forum users explicitly call out: you can display fields, but you cannot search, modify, or create those API-typed objects as Things. (Bubble)

So if your app needs “real app behavior” (filtering, analytics, sorting, deduping, joining to other Things, etc.), you’ll still end up extracting key fields into real Bubble fields or child data types.

2) Schema drift is painful

If your OpenAI output shape changes, you’ll have to re-initialize your API call (or your Bubble endpoint that returns it). Old stored blobs may not line up with the new schema, and bindings can break silently.

3) It’s easy to overuse and end up with “blob bloat”

If you store huge objects/lists as blobs everywhere, you increase payload size and complicate performance tuning. (Even if Bubble loads it, you still pay in data transfer + client-side filtering work.)

2

Firstly, an API Object is just a JSON blob of a single object, so rather than dealing with a single field that is of type text that is a JSON array (the main reason publicly addressed as to why we have WU pricing is because people were doing this and causing strain on Bubble resources with expensive fetches), with API objects you are dealing with a field that can be a single ‘thing’ (ie: a real data type that is called API Object that is part of default Bubble - Bubble has four data types, custom data types, option sets, API Objects and Plugin types; Plugin types are basically just API objects that are programmed into the plugin) or a list of ‘things’ (ie: a list of api objects).

So just based on that alone, your answer for your real question based on what you say is your real goal here:

You should make the smart decision and use API Objects instead of just a JSON array as text

NOW, what you need to be able to discern then is ‘when should I use API Objects instead of custom data types?’, which takes some thought into ideas around

  1. how the data is created
  2. how the data is fetched
  3. by who is the data fetched
  4. how often is the data modified
  5. how often is the data fetched

Those five questions can help you decide ultimately if using API objects instead of custom data types provides any type of benefit to you. Then you need to ask yourself WHY do you want to use them to begin with, which is usually for two potential purposes:

  1. Save WUs
  2. Improve UX through faster data loading and pagination

Then you can begin to ask yourself if the way in which the data is created/modified going to benefit from improved UX through advanced features mostly only attainable through use of API objects, and if you as developer want easier ways to extend your applications functionality with things like Local Storage, Index DB, integrations with AI etc. since the use of API Objects is basically just a better way to store JSON in Bubble database and the internet is powered and communicates through JSON.

Then to the point of the “omniscient“ predictor of answers (ie: the thing that makes best guess analysis based on prior knowledge - so outdated second hand accounts)

  1. You can search/filter and query it server-side like real data, you just need tools to do so. So once you get your list of API Objects into your data source running your backend workflow you can then run searches, filters etc. over that list of objects.
    1. In terms of building indexes, you can do that in several ways, one of which is to really leverage a Hybrid Data Structure approach in which custom data types have fields that are your index keys and the API Objects are stored on another field as a list - there are other ways to but you really do not need to worry as if you are making the correct decisions around when and why to use API Objects, you are not going to be dealing with more than a few thousand things at the same time.
    2. In terms of privacy rules, you can, similar to indexing, where you put fields onto custom data types to leverage bubble privacy rules. Additionally, since they are so cheap, you can just create other objects that have the private keys and value pairs removed for an additional layer of security.
    3. If you are using API Objects as a list, you can if you have the right tools to modify one object, remove it from the list and add it back to the list, or you could be ridiculous like an LLM and just replace the entire blob, but that would be a bit daft.
    4. Don’t believe everything you see on the forum, it is like Youtube, lots of people put out content that are giving bad advice. Sometimes people say things that just are not within their wheelhouse of knowledge and experience and they put out concepts and ideas that are just not aligned with reality…So, YES, you can most definitely search, modify and create API Objects with the right tool. Data Jedi Plugin does this incredibly well, and in a NoCode approach that is just like native Bubble.
  2. This is not accurate about the Schema…if you update your schema by adding new fields, nothing breaks, just the existing blobs have empty fields. If you change the names of the fields, nothing breaks, you just need to update where you parse the API Objects (again you need a tool like Data Jedi to do this well, or some other free plugins that do similar things might possibly also work) so the fields are lined up properly. But at the end of the day, it is up to the competent developer to remember things like the schema and not make changes if not necessary, and know where to make the changes, meaning should you inform OpenAI to change the schema to match the existing API Object schema inside the bubble app, or should you change the API Object schema (smart money is on the inform OpenAI to change schema side of the bet).
  3. Yes, it is easy to overuse, this is why a developer needs to think first about said questions on why and when to use them.

But at the end of the day, your post was about the choice between JSON and API Objects, not a difference between API Objects and Custom Data Types, so rest assured, your concern is clearly answered, that API Objects are the far superior choice over JSON.

3 Likes
3

OK, so you can search/sort/filter with custom data types. But privacy rules are a legit concern (I would have to create duplicate fields as you proposed).

There’s also the fact that you can’t export to csv for data analysis outside of saving the raw JSON in a text field and then having to parse/clean it up.

Just so I’m clear, let’s say OpenAI returns a “list” of Jobs, each with a salary, location, etc.

The question is, is it better to create these as separate Things with text fields (using schedule workflow on a list) or to save the entire list of jobs as one api object.

Essentially using the native database and field types vs API object type.

4

Yes, custom data types are what are known as ‘data types’ in Bubble, being the most used and understood data type available. When you use other data types, like Option Sets, API Objects and Plugin Objects, those too can be sorted and filtered, and if you structure things properly with IDs for API Objects and Plugin Objects and have the right tools, you can search for them once you have those list of objects available.

I did not propose duplicated fields. I proposed completely separate Objects with Keys removed for security concerns, which is an Additional Layer of Security which makes the API Object more secure since you can use the basic Bubble Privacy Rules on the field that is a list of the API Objects that have keys removed. Having to duplicate API Objects makes no difference to WU when you have the right tool built for working with API Objects and a Hybrid Data Structure. But at the end of the day, if you are worried you will not be able to handle security issues properly, then you might want to refrain from using API Objects or JSON for that matter on data types that have a high level of security needs, but for anybody competent enough with security and data structuring, API Objects pose no issue to security in any way, shape or form than what custom data types pose.

If you do not have the right tool, that might be true, but that is like saying, you can not bang a nail into a piece of wood when you show up without a hammer or a rock. So, get the right tools and you can export to CSV, or JSON file, or markdown or TSV or XML or HTML or text or to a base64 encoded file as well (But of course you need the right TOOL for that)

Between those two bad choices, which one is better? I do not really know as it is hard for me to evaluate two poor choices to see which one is worse. If it were me tasked with taking a ‘list’ of jobs from OpenAI, I would with the right tool, convert them to a list of API Objects in a single client side or server side action…and if I were not to choose to save that type of data as API Objects I would take from OpenAI the ‘list’ of jobs and run a Bulk Create API call to save them all as Custom Data Types.

Okay, so I think what you are actually asking is if you get a JSON array from OpenAI should you create them as custom data types or API Objects…I would like you to review my previous responses for you to have a better ability to understand the intellectual exercise you would want to undertake when making that decision for any type of data from any source you may have. Below is a copied quote from it for easier reference.

1 Like
5

Yeah.

6

You´ve come full circle @randomanon :wink:

but yea as Boston pointed out there’s pros and cons to both approaches, but storing as JSON can be hugely beneficial depending on your use case (e.g. storing lists of structured data that integrates well with the Bubble editor).

A few of the cons you can get around:

  • no visibility of the data (you can also store the JSON as plain text)
  • risk of reinitialization changing the JSON schema (think about the future use case and build flexibility into the JSON structure)

If you’re familiar with ‘data weight’ it’s important to be aware that storing as JSON objects stores the text, so loading many of these on the page are not performant,

1 Like
7

Just create the Things… The fact you’re generating them means you’re going to be doing something useful with them later and is the easiest to reason about…

8

That is just too simplistic rationale and basically ignores any reasoning of when to use API objects to benefit the app in various ways as has been discussed. Need to consider pros and cons of both as associated with use case as has been pointed out in previous replies.

9

The second you start wanting to manipulate the data in the backend, as any decent AI app built in Bubble does (AI in Bubble where the agent logic is handled in frontend is inherently limited), then it becomes tricky to deal with API Objects without server actions that are slow and cost WU.

1 Like
10

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.

1 Like
11

“Long tables” = lots of small fields on a Thing

”Wide tables” = a few small fields with a lot of stuff on them in a Thing?

Basically I am rehashing an old programming argument around “relational” and “document” databases but for Bubble.

Document-oriented database - Wikipedia

1 Like
12

I do not think this is a statement made from experience…can you give a valid concrete example where you encountered this?

Definitely a case by case basis in which the developer must think through a lot of the points previously mentioned as needing to think through to determine the Pros and Cons of using API Objects or JSON instead of Custom Data Types.

The simplest breakdown could be, if the list of objects is expected to ever grow greater than a few thousand objects, API Objects might not be the best approach, or at least need to come up with a solid way to use other data fields on the custom data type to ‘index’ the object lists. Think about storing daily logs, which, yes, can grow to be more than a few thousand, but when a list of api objects as a field is on a data type with another field that is a date, you can still retrieve quickly and easily as a user would need the data mostly through a date filter to begin with.

13

lots of small rows on a thing

lots of columns but less things

How else would you run async agents in Bubble, with tool use and looping? If you want your AI to break every time the user leaves the page etc, for sure put it in the front-end…

I assure you it comes from experience, we make AI agents natively in Bubble that do stuff like code execution, AI native file processing, web browsing etc…

1 Like
14

I didn’t say you don’t have experience with AI agents. I’ve seen the post you put up about how you built something for AI and the follow up explaining your rationale for why you built it the way you built it. The AI was not subject of this thread, so my saying you had no experience was based around use of API Objects, or at least no experience to have made a qualified assertion that use of API Objects versus custom data types for AI interactions was poor choice.

This is definitely not an assertion based on experience using API Objects in the backend and I know this because in my experience working with API Objects in the backend I know that they work just like custom data type fields, because they are one of four data types Bubble has built into the platform natively. I’ve explained this to you many times on the forum already…everything you can do with custom data types you can do with api objects in regards to custom expressions. The only ‘difficult’ (and let’s face reality, difficult doesn’t mean impossible, just means ‘need to think logically about something slightly complex’) is how to get an API object from front end to back end because schedule backend workflows action doesn’t accept api objects as parameters. But of course, once in the backend if a custom data type that is structured using a Hybrid Data Structure which has API objects as fields, they are just as easily accessible and easy to manipulate as custom data type fields.

Every server side action costs WUs. And using actions server side for API objects is not inherently slow.

I think your confusion comes from a misunderstanding of how to use API objects or Why. Yes, it is very common for people to use them primarily on front end for purposes of cheap data, but they are part of native bubble and accessible everywhere via dynamic expressions. So, I suppose to answer your question of ‘How else would you run async agents in Bubble, with tool use and looping’ the answer would be in the backend workflows. Because you surely are not limited to using API Objects only on the front end.

But could you give a concrete example of your experience encountering the manipulation of API objects in the backend trickier, slower or more WU intensive than custom data types? I’d be happy to help you get around the hurdles you encountered.

15

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

16

The API connector can also be used for this use case.

17

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

18

Fair enough, but there are absolutely use cases where API objects/Structured data are beneficial, and some where it wouldn’t make sense - the answer as always is “it depends”.

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.

2 Likes
19

Why not?

Having them as database rows would let you easily do things like let users mark them as complete, let you do analytics like the user’s grammar ‘score’ over time, recurring issues (Search for Fixes :grouped by issue). Of course, arbitrary example, but you get heaps more flexibility as a data type and it’s not clear to me what’s the issue with making it a data type.

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.

1 Like
20

This is where it comes down to “it depends” and foreseeing functionality that may be required in future and what the actual use is - sometimes you never will never need the analytics, but would still want the flexibility of parsing the data.

Another arbitrary example in terms of scale of my example, there might be 200 fixes in one User’s input. If there’s 10 users in the app creating 5 of these hourly, already you’re creating 10,000 things/hour.

The root of my argument is that sometimes there’s things that are useful to parse, rather than plaintext/other DB fields.

2 Likes