11-10-2016 06:27
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

11-10-2016 06:27
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
My team is trying to address the Rate Limit errors that we have been receiving. We are trying to prevent reaching the limit by using the “Fitbit-Rate-Limit-Remaining” header.
Using Fiddler, we noticed that this value is not being correctly decremented on each subsequent request. However, the Rate Limit error is still received right after a response that might say “Fitbit-Rate-Limit-Remaining: 144”.
I am sending some screenshots with our proof.
ç
Answered! Go to the Best Answer.

Accepted Solutions
12-01-2016 17:45
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



12-01-2016 17:45
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
- Who Voted for this post?
The rate limit headers now are approximate and asynchronously updated. Previously, they were updated on every request. This means that there may be a minor delay in the decrementing the remaining requests. This will result in your application being able to make a few extra requests per user per hour and potentially having a surprise 429 response if you don't track the total number of requests you make yourself.
11-11-2016 13:34
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



11-11-2016 13:34
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
@FedericoArg Yeah I was able to reproduce the same thing, appears to be a bug. Thanks for bringing it to our attention.

12-01-2016 04:44
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

12-01-2016 04:44
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
@AndrewFitbit Did your team make any progress about this issue?

12-01-2016 17:45
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



12-01-2016 17:45
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
- Who Voted for this post?
The rate limit headers now are approximate and asynchronously updated. Previously, they were updated on every request. This means that there may be a minor delay in the decrementing the remaining requests. This will result in your application being able to make a few extra requests per user per hour and potentially having a surprise 429 response if you don't track the total number of requests you make yourself.
