Is there a way to get all sleep values, wether it be main...

[Bonxy]

Is there a way to get all sleep values, wether it be main or secondary values of sleep but in a time series format ? Im using the current time series but like others im noticing the difference in sleep values.

[SamVerschueren]

Well, this is a bummer. When a user authenticates with our application, we want to retrieve the sleep of the last month. When using the time-series, this is really easy to do. But apparantly, this doesn't match the "correct" time the user slept. So we will have to call the API 30 times instead of 1 time.

Returning the main sleep in the time series in my opinion is useless. This night I slept 3 blocks of 3 hours. So in total I really slept 9 hours. But the time series API just returns 3 hours. This might be documented that this is the case, but that value really means nothing to me, nor the users of my application. I couldn't think of a use case where the main sleep value is good enough.

[Bonxy]

I to find this really annoying.

I didnt realise the time series only returned the main sleep until I read the docs. I do find it a bit useless.

I joined Fitbit In March 2014 so that's 500+ logs.

I would have to do 500 different requests to get all my sleep data.

When you have over a 1000 users with some who joined Fitbit in 2010 this is an enormous task with the rate limit in place.

[Michael]

---

@Bonxy wrote:

When you have over a 1000 users with some who joined Fitbit in 2010 this is an enormous task with the rate limit in place.

---

@Bonxy The number of users shouldn't make any difference, the rate limit is per user per app, not per app. (Unless of course you are making non-user calls at the same time which would fall under a per app rate limit.)

[Bonxy]

It does if your having to make on average 500 extra requests per user just to get the sleep.

Servers have limits too.

[JeremiahFitbit · Accepted solution]

---

@Bonxy wrote:
I joined Fitbit In March 2014 so that's 500+ logs.

I would have to do 500 different requests to get all my sleep data.

When you have over a 1000 users with some who joined Fitbit in 2010 this is an enormous task with the rate limit in place.

---

I know that backfilling a user's historic Fitbit data is an API request intensive use-case that is not well handled by the current design of the Fitbit API.

Many historic data queries create a burden on the Fitbit API infrastructure. Recent data is heavily cached, as it is the most frequently accessed data. As data ages, it is bumped from our database cache. Retrieving non-cached data creates more overhead for our database, especially if your application has many users. For this reason, we require that applications doing this stay within the standard API rate limit.

We are working on a better long-term solution for this use-case. Unfortunately, I don't have a time frame for this improvement.

[Bonxy]

I understand. I'm glad changes may be made in the future.

I guess I'll manage with the way it is for now. 🙂