Naming convention in bulk API has changed? `datatype` instead of `data_type`?

I’ve built a handful of actions using the bulk API endpoints. This morning I was trying to create another one and it kept on 404’ing.

The data type is called Question Tag which I would expect the endpoint to be:

.../api/1.1/obj/question_tag/bulk

But it was actually
.../api/1.1/obj/questiontag/bulk

I rechecked a bunch of my other APIs and they all work with _ for spaces. And now they all work with no-spaces too. Previously created APIs work with both _ and no-space while newly created ones only work with no-space.

So for a previously created API both of these work:

.../api/1.1/obj/question_set_item/bulk

.../api/1.1/obj/questionsetitem/bulk

I checked the meta endpoint and I see this:

...
"get": [
        "answer",
        "assessmentstats",
        "question",
        "questionsetitem",
        "questiontag"
    ],
...

Am I going insane? Have these things always been there?


Nudging Mr. Documentation @petter in case he’s looking for more stuff to improve.

To my knowledge it’s always been remove spaces completely, interesting that it worked for you previously. Maybe the behaviour was poorly defined :man_shrugging:

1 Like

May be a little known fact that if you change the name of a datatype, Bubble will update the API endpoint to the new name but also keep working for the old name… so perhaps that’s what happened here. Here are my notes on the subject;

A table from a Bubble app, assuming it is exposed via API, can be accessed the following URL:

https://example.com/version-test/api/1.1/obj/conversation

where conversation above is the name of the table we want to fetch. There are only two names that can correctly resolve to a Bubble database:

  • the original name of the table (however it was spelled)
  • the current name of the table

In many cases those two names are the same name.

That said, any non alphanumeric character EXCEPT FOR UNDERSCORE in a Bubble table name needs to be changed to an underscore in order to correctly address it via API. Spaces and Case are completely ignored so Table named Kool Cars can be queried at any of the follow URLs

keywords: column names, bubble fields

At any point, the correct name for a Bubble Table can be accessed using the %d key for any key listed under app.user_types

Image

3 Likes

Hey @zelus_pudding , where can I read a little bit more about this? I got the principles about data type names, I would just like to learn more about data type fields (I already know about the field id, but what can be used in the display itself, spaces, icons, emojis, what convention of names would be better to avoid any problems in future integrations?

Thanks in advance.

Name of the game with anything concerning Bubble’s backend is trial and error - that’s how I learned about those things (which I’ve really needed to build complex plugins). I don’t have a manual entry I can refer you to.

In general, never use an empojii in a datatype name. Lol, that’s the worst. Bubble’s backend is going to be forgiving with that (they replace it with an underscore) but that’s going to create a lot of disonnance for you and anyone who tries working with your application… they’ll have to wonder how to handle that even in the best of times and how to work around it when it (eventually) breaks something about your app.

My habit for creating bullet proof names is to only use

  • letters
  • underscores.

Nothing else - not even spaces. For boolean fields, instead of saying something like we_cool? I write is_cool. Those are my personal rules but Bubble is definitely okay with using space (you’ll/your developer will just have to remember to replace those for underscores when working with the backend).

2 Likes