11-10-2016 06:27
11-10-2016 06:27
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.
Best Answer12-01-2016 17:45
Fitbit Developers oversee the SDK and API forums. We're here to answer questions about Fitbit developer tools, assist with projects, and make sure your voice is heard by the development team.
12-01-2016 17:45
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
Community Moderator Alumni are previous members of the Moderation Team, which ensures conversations are friendly, factual, and on-topic. Moderators are here to answer questions, escalate bugs, and make sure your voice is heard by the larger Fitbit team. Learn more
11-11-2016 13:34
@FedericoArg Yeah I was able to reproduce the same thing, appears to be a bug. Thanks for bringing it to our attention.
Best Answer12-01-2016 04:44
12-01-2016 04:44
@AndrewFitbit Did your team make any progress about this issue?
Best Answer12-01-2016 17:45
Fitbit Developers oversee the SDK and API forums. We're here to answer questions about Fitbit developer tools, assist with projects, and make sure your voice is heard by the development team.
12-01-2016 17:45
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.