Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

intraday for multiple days

ANSWERED

We have partner access, and are attempting to synchronizing multiple people/devices over multiple days with intraday granularity at 15 minute intervals. It appears as though we need to make a separate call for each day for teh intraday information. However, this seems like a lot of overhead if we are synching many users who have not synched in some time.

 

My questions:

1) Is there a way to wrap intraday queries for multiple days in one request?

 

2) If not, and we need to submit each day as a separate request for each day (for example for a month):

activities/calories * 30
activities/steps * 30
activities/distance * 30
activities/floors  * 30
activities/elevation, * 30

along with requests for daily summary data

It seems as though we will run into trouble with your rate limits, especially for those users who have not synched in slightly less than a month. Or am I missing something?

 

3) Given these possible constraints in quering, do partners have a highr rate limit?

 

Please advise.

 

Looking forward to your reply. 

 

~matthew

 

Best Answer
0 Votes
1 BEST ANSWER

Accepted Solutions

1) No, due to the size of these responses, they are limited to 24 hours of data.

 

2 & 3) 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 caches. 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 and gradually backfill users' data.

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

View best answer in original post

Best Answer
8 REPLIES 8

1) No, due to the size of these responses, they are limited to 24 hours of data.

 

2 & 3) 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 caches. 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 and gradually backfill users' data.

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

Best Answer

That's good to hear.

Best Answer
0 Votes

It isn't good to hear. Shows that they do not trust in their databases. It is an endemic problem in the developer community. Probably using NoSQL as well...

Best Answer
0 Votes

@R8VXF wrote:

It isn't good to hear. Shows that they do not trust in their databases. It is an endemic problem in the developer community. Probably using NoSQL as well...


If you're claiming to be an expert, we're hiring.

Best Answer
0 Votes

Telecommute from the UK as your BI lead developer? (I sideline as a DBA)

Best Answer
0 Votes

Dammit, same here. 

 

If the database is such a sore point - people should get a chance at the 1 minute data before it's uploaded to the fitbit servers during sync.

 

As a conspiracy theorist - I think there's more to it than the DB being ropey. There's a high percentage of HR users want that data - many threads in the forums. Fitbit are aware they want it, and yet it's not being offered on the moment of upload. To me that sounds very likely to be a corporate decision based on bids for the data.

I certainly can't beleive no one had thought of that.

 

Best Answer
0 Votes

@SarahC_ wrote:

As a conspiracy theorist - I think there's more to it than the DB being ropey. There's a high percentage of HR users want that data - many threads in the forums. Fitbit are aware they want it, and yet it's not being offered on the moment of upload. To me that sounds very likely to be a corporate decision based on bids for the data.

I certainly can't beleive no one had thought of that.


@SarahC_: I'm happy to debunk this conspiracy theory. 🙂 Fitbit believes that users own their data and has demonstrated this by granting every personal request to access heart rate intraday data via the Fitbit API. Fitbit doesn't sell data and it has no incentive to limit access to your own data.

 

The heart rate data actually is available from the moment it's uploaded. What's been discussed in this topic is the API design, which intentionally limits the amount of data returned per request (up to 24 hours) due to the size of the response, and the rate limit, which is a traffic control we use to ensure the API is highly available to the millions of Fitbit users and thousands of applications using the Fitbit API.

Best Answer

May I suggest then that you update the API documentation to indicate in the list of "Resource URLs" that the very first documented format is ineffective in retrieving intraday data for the specified date range? I wasted a bunch of time trying to get that to work.

Best Answer
0 Votes