Any idea why when I run a GET request to the Bubbe Data API I’d get only some of the fields in the table back? I’ve set the privacy permissions to “view all fields”. The newer fields I’ve created don’t show up in the GET result.
1 Like
Go back to your GET api settings and double check that the new created fields are also checked. If you made the data api avail before creating extra fields in that particular thing, there is a good chance this is the issue.
1 Like
Where do I select individual fields? I selected the whole table in the setting > API…
sorry, i was trying to avoid a large explanation and solve your issue at the same time 
, after you created a new field and as you mention allowed for privacy, making sure the data api check is checked for the thing you need to push to live to have the fields available for the thing. after i write this someone is going to tell me im nuts and its available in the test version of the data api, this is true - but depending on how your calling the api (version-test/api or /api) you can easily be sitting on your version-test site calling your live endpoint. another thing we have found is with dedicated/non dedicated there seems to be flip flop results while testing between the api version’s with the exact same code. how exactly are you attempting to access the api? and what is the url your making a request to?
I created a few new fields in our user table on dev. I flipped on the Data API for the users table in setting > api. I enabled the privacy modify a thing on user.
Now, I’m using POSTman to GET data on a user in dev. https://meetaway.com/version-test/api/1.1/obj/user/<user$unique_id>. I get a response with data, but the response doesn’t contain the new fields I created.
Is there something else I should try?
if your have hit the same annoying issue i hit on occasion, that being you ensure the GET request is infact version-test/api, the quickest way ive found to just get on with what im doing is to push to live. then those fields magically become available in both the test & live api versions. even more annoying is this is not consistent between dedi/non dedi.
1 Like
perhaps try replacing meetaway.com with either d**.bubble.is or yourappname.bubbleapps.io depending on dedi/non dedi. the result could be interesting or no change.
Thanks. I’ll give them both a try. Appreicate the help.
no worries, another thing you could investigate is making a GET request to /version-test/api/1.1/meta and /api/1.1/meta this will give you a quick insite to the look of your things/fields without the entire swagger file in the way.
Still not working. I’ll submit a bug report.
As it turns out, the GET doesn’t return columns if all values in the column are blank.
I was creating new columns and using the GET to return the exact column name so that I could set up an API call to populate the column values. Adding a value to the new column solved the issue.
3 Likes
That is the number 1 thing that drives dev time up when integrating a services api… to many times ive have to create whole objects to return a complete response from a provider just to be able to reference it.
2 Likes
Yep you’re perfectly right. I realized it and that is why i deleted my initial post. I was going to create a new post about it.
I really don’t understand the reason behind this design decision.
Yes @jarrad it is really frustrating. I’m connecting a dropsource app to bubble and my app was crashing inconsistently and i didn’t understand. Just realized this is the reason because some times the app is not receiving a field when it is empty.