help menu

Join us on the Community Forums!

  • Community Guidelines

    The Fitbit Community is a gathering place for real people who wish to exchange ideas, solutions, tips, techniques, and insight about the Fitbit products and services they love. By joining our Community, you agree to uphold these guidelines, so please take a moment to look them over.

  • Learn the Basics

    Check out our Frequently Asked Questions page for information on Community features, and tips to make the most of your time here.

  • Join the Community!

    Join an existing conversation, or start a new thread to ask your question. Creating your account is completely free, and takes about a minute.

Not finding your answer on the Community Forums?

Cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

API Rate Limit

‎10-02-2015 14:31

‎10-02-2015 14:31

Just trying to download my wife's and my own data at intraday level, but keep smashing into the api rate limit of 150(??) requests/hr per logged in user. I realise I can contact the api team and ask for a higher limit (maybe just for a short term so I can get the data down), but wondered why such a low limit for a company who is supposedly one of the largest fitness firms on the planet? I was just wondering what sort of overall rpm you were seeing that 150rph was considered sensible? Maybe at least double it to 365 so we can get a years worth of data per activity per user an hour.

 

 

Best Answer
Labels:
0 Votes
5 REPLIES 5

‎10-02-2015 14:46

‎10-02-2015 14:46

We 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.

 

Keep in mind the rate limit resets at the top of the hour and you are immediately able to make another 150 requests at that time. We understand that this isn't ideal from your application point of view and you will need to implement a little more additional logic to wait for the rate limit reset.

Best Answer
0 Votes

‎10-02-2015 15:02

In response to SunsetRunner

‎10-02-2015 15:02

Sorry, as a DBA, that is a C&P pasted bs response. you are basically relying on fastly or some other CDN for caching rather than improving your owncapabilities. The same response was posted over a year ago on these very same forums. Bet your hit rates are not actually that high and you really need a decent DBA to sort your DB design out.

 

I have 2 users. Me and my wife. I have 59 minutes an hour to get bored of waiting to load another few days worth of data. Try employing a good DBA. you would be amazed what a database really can do.

Best Answer
0 Votes

‎10-02-2015 15:13

In response to R8VXF

‎10-02-2015 15:13

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

Best Answer

‎10-02-2015 15:16

In response to JeremiahFitbit

‎10-02-2015 15:16

Not in the UK you aren't.

Best Answer
0 Votes

‎10-02-2015 15:17

In response to R8VXF

‎10-02-2015 15:17

And there is no claim about it. I am good at what I do. I am just very belligerant due to dealing with developers 😉

Best Answer
0 Votes