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:
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:
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
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?
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).