Water data not coming through correctly.

[DonDickinson]

As of app version 4.39 of the fitbit app, our web api retrieval of the data is no longer receiving water data in ML. Our app will take the api data and multiply the number of ML reported by .033814 to convert it to OZ. Any of our users who are integrating with us via the fitbit app less than 4.39 are getting correct OZ of water in our system. However, anyone who updated to 4.39 or greater now has their water coming to us with a much bigger number. In order to convert that number correctly to OZ, I have to multiply .033814 two times. For example:

App users less than 4.39 might have data looking like this (correct)

{date: YYYY-MM-DD, value: 1892.7099609375}

when I multiply 1892 by .033813 I will correctly receive the recorded 64 OZ.

App users 4.39 app version and greater will look like this:

{date: YYYY-MM-DD, value: 62970.69921875}

To get the correct 72 OZ I have to multiply 62970 times .033813 two times. So the Unit of measure being sent is no longer ML. I have no idea what it is, but it sure seems bugged. This is causing an absolute mess in our data store for thousands of users. Please help.

[IncaFitbit]

Hi @DonDickinson ,

Thank you for reaching out us for this issue.

For the unit in the Water API response, you can set the Request header `accept-language`.
The units of measurement used can vary based on the language., e.g. when the accept-language is en_US, it return the amount in fl, oz. Please see this link for more details.

Regarding the return value, I tested the endpoint using the Fitbit Web API Explorer, and it functioned correctly with my Android Fitbit app version 4.40 water data.

Could you please try testing the water API endpoints again using the Fitbit Web API Explorer to see if you still encounter the same response? If the issue persists, could you provide the following information?
1. Does this issue occur on a specific platform (Android or iOS)?
2. Which API call are you testing, and what is the Fitbit app version you are using for the test?
3. Could you also share a screenshot of your Fitbit water page and the corresponding API response?

Thank you,
Inca

[DonDickinson]

I want to be clear that this is multiple users (800+) who have water connected to our app. Not all have experienced this problem. Our data retrieval code has not changed in more than a year. The people who are experiencing the issue have v3.39+ of the Apple Fitbit app. Our in-house ios/fitbit test device (data below) had water coming in correctly in mL on Monday. On Monday we updated from v4.35 to the latest (4.41) and we started seeing the inflated non-mL number.

Our headers are the same for all users and request English. The unit of measure coming through is mL and the numbers can correctly be converted into ounces until v3.39 of the apple fitbit app, then the data is mL * 29.567079 (to get Oz you multiply * .0338214 two times - meaning I have to do the mL to Oz calculation twice). Prior to v3.39, I get a smaller number that is absolutely mL. I convert to Oz by multiplying * .0338214.

We are looking for "foods-log-water" in the return data.

Here is the URL used for data retrieval of the two samples (Fitbit ID redacted, but I can provide if necessary)
NOTE - the forum software *would not* let me post the year in the Ymd format. So, I replaced all occurrences of 2025 dash 04 with YYYY-MM in the text below.

https://api.fitbit.com/1.2/user/{IDREDACTED}/foods/log/water/date/YYYY-MM-08/YYYY-MM-18.json

Here is the .JSON returned for someone on v4.41
{"foods-log-water":[
{"dateTime":"YYYY-MM-08","value":"0.0"},
{"dateTime":"YYYY-MM-09","value":"0.0"},
{"dateTime":"YYYY-MM-10","value":"0.0"},
{"dateTime":"YYYY-MM-11","value":"29773.5"},
{"dateTime":"YYYY-MM-12","value":"0.0"},
{"dateTime":"YYYY-MM-13","value":"48977.19921875"},
{"dateTime":"YYYY-MM-14","value":"69967.3984375"},
{"dateTime":"YYYY-MM-15","value":"0.0"},
{"dateTime":"YYYY-MM-16","value":"0.0"},
{"dateTime":"YYYY-MM-17","value":"62970.69921875"},
{"dateTime":"YYYY-MM-18","value":"13993.5"}
]
}

Here is the .JSON returned for someone who is on a pre-4.39
{"foods-log-water":[
{"dateTime":"YYYY-MM-08","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-09","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-10","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-11","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-12","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-13","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-14","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-15","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-16","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-17","value":"1892.7099609375"},
{"dateTime":"YYYY-MM-18","value":"1892.7099609375"}
]
}

[DonDickinson]

Here is a screenshot from the user above with the 29773.5 value on Apr 11.

This *is not mL* ... if it were you could multiply by .0338214 you will get 34 oz. If you do this math 2 times - 29773.5*.0338214*.0338214 you will get the 34oz. In the past versions (like the 2nd example above) the value would have been about 1006.98 not 29773.5 because 1006.98 mL * .0338214 = 34 Oz

[IncaFitbit]

Hi @DonDickinson ,

Thanks for the confirming that you are using the "Get Nutrition Time Series by Date Range" for retrieving water data. 

I've compared the API endpoint you provided with the one documented, and it appears there might be a slight discrepancy in the path.

• Your endpoint:  https://api.fitbit.com/1.2/user/{IDREDACTED}/foods/log/water/date/YYYY-MM-08/YYYY-MM-18.json
• Documented endpoint: /1/user/[user-id]/foods/log/[resource]/date/[start-date]/[end-date].json

My Android 4.40 and iOS 4.41 data can be retrieved correctly by the documented endpoint through Fitbit Web API Explorer, this suggests the issue you're encountering might indeed be related to the endpoint path you're using.

I'll be checking internally on how to prevent fetching data from potentially incorrect endpoints to avoid unexpected results in the future.
Thanks for bringing this to our attention!

Best regards,
Inca

[DonDickinson]

Unfortunately, the new end point *did not* fix the issue. I can provide the Fitbit ID for this person if you want to check it out (DM?) or maybe just post it (not sure of security implications). This is iOS app ver 4.41

New water entered for today, Apr 21 was 32 Oz. April 18 was 16oz. That should have come through with a value of approximately 473 mL and 947 mL respectively. Again, the forum software won't let me post 2025 dash 04, so I replaced it with YYYY-MM

https://api.fitbit.com/1/user/{FITBITID}/foods/log/water/date/YYYY-MM-11/YYYY-MM-21.json

{"foods-log-water":[
{"dateTime":"YYYY-MM-11","value":"29773.5"},
{"dateTime":"YYYY-MM-12","value":"0.0"},
{"dateTime":"YYYY-MM-13","value":"48977.19921875"},
{"dateTime":"YYYY-MM-14","value":"69967.3984375"},
{"dateTime":"YYYY-MM-15","value":"0.0"},
{"dateTime":"YYYY-MM-16","value":"0.0"},
{"dateTime":"YYYY-MM-17","value":"62970.69921875"},
{"dateTime":"YYYY-MM-18","value":"13993.5"},
{"dateTime":"YYYY-MM-19","value":"0.0"},
{"dateTime":"YYYY-MM-20","value":"0.0"},
{"dateTime":"YYYY-MM-21","value":"27987.0"}]}

[DonDickinson]

Here is another, perhaps better example, that retrieves water day back for 30 days from today - Mar 22 thru Apr 21. the user updated their app on Apr 8. All results are for logging 65 oz of water except for today which has no water. You can see the water increase on that day by 29.567 times (the conversion from Oz to mL done two times). Again, I can provide the {FITBITUSER} in a DM or whatever.

https://api.fitbit.com/1/user/{FITBITUSER}/foods/log/water/date/YYYY-MM-22//YYYY-MM-21.json

{"foods-log-water":[
{"dateTime":"YYYY-MM-22","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-23","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-24","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-25","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-26","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-27","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-28","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-29","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-30","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-31","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-01","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-02","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-03","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-04","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-05","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-06","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-07","value":"1922.280029296875"},
{"dateTime":"YYYY-MM-08","value":"56848.5"},
{"dateTime":"YYYY-MM-09","value":"56848.5"},
{"dateTime":"YYYY-MM-10","value":"56848.5"},
{"dateTime":"YYYY-MM-11","value":"56848.5"},
{"dateTime":"YYYY-MM-12","value":"56848.5"},
{"dateTime":"YYYY-MM-13","value":"56848.5"},
{"dateTime":"YYYY-MM-14","value":"56848.5"},
{"dateTime":"YYYY-MM-15","value":"56848.5"},
{"dateTime":"YYYY-MM-16","value":"56848.5"},
{"dateTime":"YYYY-MM-17","value":"56848.5"},
{"dateTime":"YYYY-MM-18","value":"56848.5"},
{"dateTime":"YYYY-MM-19","value":"56848.5"},
{"dateTime":"YYYY-MM-20","value":"56848.5"},
{"dateTime":"YYYY-MM-21","value":"0.0"}]}

[IncaFitbit]

Hi @DonDickinson ,

We need your client ID and affected user ids for advanced investigation.
Can you provide above information to me in DM? thanks!

Inca

[DonDickinson]

I sent you the DM. I only gave you the one affected ID that corresponds to the data in the last post. I can come up with many more examples if needed. This is not an isolated thing. Every one of our users (as far as I can tell) that updated beyond 4.38 is having their water entered in Oz converted to mL two times (inflating the number as in the example above). for all data entered by them after the update. Thanks for your help.

-Don

[IncaFitbit]

Hi @DonDickinson ,

Thanks for sharing your clientID! While looking into this, I came across another IssueTracker ticket with the same clientID.
To help us keep things organized, would you mind checking if you created that ticket as well?
If that's the case, it would be great to continue our discussion directly on that IssueTracker ticket to ensure everything is tracked efficiently in one place.

Please let me know. Thank you!
Inca

[DonDickinson]

It was not me that created that ticket. However, I did ask around and  another employee (initials DS) did put in that ticket. It doesn't matter to me if you wish to discuss via that ticket. I'll have him share with me anything you communicate in that manner. I am also happy to continue the discussion here.

[IncaFitbit]

Hi @DonDickinson ,

Yes, let's continue our discussion on the Issue Tracker ticket. You can ask your colleague to CC you on the ticket so you can also stay informed of any updates.

We were able to reproduce this issue last week and have already reported it to our engineering team. We'll be sure to update you as soon as we receive any new information.

Inca

[IncaFitbit]

Hi @DonDickinson ,

Engineering identified the issue and we're working on a fix. In the meantime, you can try the workaround posted below until a fix is deployed.

The absence of the Accept-Languageheader in the IOS v4.39 update, is causing water log creation requests in the backend to misinterpret milliliter values as fluid ounces.
Workaround: Specify the Accept-Language header in API requests to provide correct results.

Above information is also updated in the IssueTracker ticket.

Regards,
Inca

[DonDickinson]

I'll keep communicating in the issue tracker via my co-worker, but I wanted you to know it is not fixed. This does not work. I added the accept-language header and specified en-US, but the data retrieve remained exactly the same. I bother to post this here because, despite my giving another example in the issue tracker and updating the on the new headers, they marked the issue "Fixed".