BodyTimeSeries stopped returning weight and bmi prior to some date

[pwstern]

I created an app that uses the BodyTimeSeries endpoint to fetch weight, bmi, and fat going back to 2013 (in 3 year chunks).  Recently, the endpoint started returning a non-changing weight and bmi prior to 10/23/2022.  The endpoint returns the correct changing data for "fat" over the full range of dates.

When my wife runs the app, her data freezes for dates before 9/18/2018.  Like mine, this occurs for weight and bmi, but not fat.  The "freeze date" is different, but repeatable for each user.

I've been using the Authorization Code Grant Flow (OAuth 2.0) with no issues since creating the app in 2020.

[patrick40]

I'm noticing the same bug. All weighins before 02/09/2020 are the same (but I should have varying weighin data going back to 2009).

This used to work.

[bryen_joker33]

Bro I have run into something similar before, and it usually points to an issue on the provider’s side, not your code. When weight and BMI freeze at a specific date but fat data stays normal, it’s often a backend sync or historical data bug. The fact that the “freeze date” is different but consistent per user makes it even more likely. When I was testing this while working on my Hypic project, opening a support ticket with logs usually got them to refresh or fix the data source internally.

[pwstern]

I started a Chat session with Juan from Fitbit on 11/19/25 and got this response...

"As you know, Google acquired Fitbit. This is leading to a platform consolidation that may impact the application you created

The Fitbit Web API you are using is an older, legacy API. While Google has announced that the API endpoints and OAuth 2.0 authorizations will continue to operate for the time being

Google is focusing its resources on its new health platforms.

Google has officially announced that the Google Fit APIs will be fully deprecated by 2026 and strongly encourages migration to Health Connect.

While the Fitbit Web API has not been given a shutdown date, it is the platform's oldest API. To ensure the long-term viability of your application, you should plan for a migration.

Given your app is running on iOS (as you mentioned), and the data involves weight and body measurements, we recommend keeping a close watch on Google's Developer announcements for the future of the Fitbit Web API. If your app were Android-only, the recommendation would be to migrate to Health Connect, which is the unified health platform on Android.

I understand that this is a complex issue requiring a technical response. I can open a formal consultation with our specialized team for you.

If so, you will receive a direct response from the specialized team within the next 24 to 48 business hours, with steps to address the current issue and information regarding the API's future roadmap."

I have not heard back from them.

[Gondwana]

That info seems a bit confused to me. Google Fit is unrelated to Fitbit, so its deprecation is not relevant.

[patrick40]

I have an open IssueTracker ticket with engineering, they are investigating. Originally they closed the ticket saying it was working as expected but then I provided more details, the ticket is in the "assigned" state.

@pwstern what I noticed is that I was able to get around this "freeze date" issue by using the https://api.fitbit.com/1/user/-/body/log/weight/date/[INSERT_DATE]/1m.json endpoint instead of using the https://api.fitbit.com/1/user/-/body/weight/date/[INSERT_DATE]/max.json  

It takes a lot more API calls doing it that way... Are you able to reproduce that? If so it would seem that it's only isolated to the "max" period.

[pwstern]

@patrick40 I appreciate you looking into this.

I have been using the "Get Body Time Series by Date Range" endpoint (ex. https://api.fitbit.com/1/user/[user-id]/body/weight/date/[begin-date]/[end-date].json ), since it has a maximum range of 1095 days per fetch request.

As you mentioned, using the "Get Weight Time Series by Date" endpoint takes many more API calls (36 requests for the same amount of data) and quickly runs into the 150 requests per hour limit.

[pwstern]

@patrick40 I did some more investigating.  Here is a summary of what I found...

Endpoint Name	Supported Periods	URI	Data Freeze?
"Get Body Time Series by Date"	1d, 7d, 30d, 1w, 1m, 3m, 6m, 1y, max (3 years max)	https://api.fitbit.com/1/user/-/body/weight/date/[end-date]/[period].json	Yes, if period contains freeze date
"Get Body Time Series by Date Range"	N/A (3 years max)	https://api.fitbit.com/1/user/-/body/weight/date/[start-date]/[end-date].json	Yes, if date range contains freeze date
"Get Weight Time Series by Date"	1d, 7d, 30d, 1w, 1m (1 month max)	https://api.fitbit.com/1/user/-/body/log/weight/date/[end-date]/[period].json	No
"Get Weight Time Series by Date Range"	N/A (1 month max)	https://api.fitbit.com/1/user/-/body/log/weight/date/[start-date]/[end-date].json	No

The "Get Weight Time Series..." endpoints don't freeze, but don't provide a large enough date range to be useful for my needs (quickly run into the 150 requests per hour limit).