08-04-2025 13:17
08-04-2025 13:17
In the Fitbit Web API documentation, the logged food JSON key is called 'loggedFood', but we now see in user data that this has changed to "logged_food":
{"foods":[{"logId":36982634939,"logged_food":{"foodId":0,
Can this be fixed, to match with the description in the documentation, or should we change it in our app?
Answered! Go to the Best Answer.
08-07-2025 10:24
08-07-2025 10:24
Engineering has rolled back the change that caused the response element names to change. The problem should be resolved.
08-04-2025 13:27
08-04-2025 13:27
Some fields within the logged_food have also changed to snake_case, including mealTypeId, nutritionalValues, and accessLevel. But foodId is still camelCase so it's not consistent.
08-05-2025 04:30
08-05-2025 04:30
We see that this issue with logged_food, and meal_type_id etc., doesn't happen for all Fitbit users. We can't reproduce it on our test devices. But for example for user with id CBMNZH the JSON fields are changed when we request the data.
If more information is needed (for Fitbit support) please let me know.
08-05-2025 06:46 - edited 08-05-2025 06:46
08-05-2025 06:46 - edited 08-05-2025 06:46
We even see that with a user the nutrition data almost every time is using 'logged_food' (and the other _ variants) but sometimes for the same request and same response, it uses 'loggedFood' (changed the date because date format used in JSON is not allowed on this forum):
{"foods":[{"isFavorite":false,"logDate":"..August 5...","logId":36986929041,"loggedFood":{"accessLevel":"PUBLIC","amount":1,"brand":"","calories":323,"foodId":537131397,"locale":"de_DE",
And an hour later when we do the same request and no new nutrition data is available, so exactly the same response (with another order of the fields):
{"foods":[{"logId":36986929041,"logged_food":{"foodId":537131397,"access_level":"PUBLIC","locale":"de_DE", .... "logDate":"...August 5...","is_favorite":false,
08-06-2025 07:52
08-06-2025 07:52
Thank you for posting this problem. I'm currently looking into it.
08-06-2025 08:06
08-06-2025 08:06
I have filed a bug to engineering. I'll respond here with what I find out.
08-06-2025 08:57
08-06-2025 08:57
Possibly related problem in the Android app:
https://community.fitbit.com/t5/Android-App/Food-log-quot-tile-quot-blank/td-p/5772526
08-06-2025 09:10
08-06-2025 09:10
The problem is when water is logged in the mobile app, the water data is not returned by the Get Water Log endpoint. This could have a wide-spread issue with 3P applications that pull water data from Fitbit. If you create a water log with the Create Water Log endpoint, the water data is returned by Get Water Log.
08-06-2025 10:10
08-06-2025 10:10
yes we are also experiencing a ton of user complaints because their food is not syncing as the properties have been suddenly changed! Can they please be changed back?
08-06-2025 10:22
08-06-2025 10:22
are you referring to the property names being changed? I am not sure I understand why logging water could cause property names to change?
08-06-2025 13:11
08-06-2025 13:11
Hi @trevor_chong I think there is a mix in this topic: it is about nutrition data and changed field names in the Fitbit JSON response, I think @GordonFitbit accidentally wrote a comment about the water intake issue (which I reported in another topic) in this topic. Gordon already mentioned that the issue is being reported as a bug to Fitbit engineering, so let's hope there is a fix soon.
08-07-2025 09:40
08-07-2025 09:40
@GordonFitbit any updates? We already patched the modified property names in our system, but now it seems the meal types are an issue where our code that relies on that model coming back is not receiving proper info to classify the meal types (breakfast, lunch, dinner).
08-07-2025 10:24
08-07-2025 10:24
Engineering has rolled back the change that caused the response element names to change. The problem should be resolved.