It's better to use the responses from the API to update your rate limiter. The headers X-Ratelimit-Limit and X-Ratelimit-Usage contain information about what the current limits are and how much you've used.

As far as I know, OAuth requests are not used for counting towards the rate limit.

Confirming that OAuth requests do not count towards your rate limit.

In addition to the usage headers, you can also see your usage in your API settings dashboard 🙂 

Yes but using the headers to update my rate limiter does not help me with better managing my calls over the 15min and 24h limit time frames. For instance if I see that I have still 50 calls left in this 15min time frame, it does not tell me whether the time frame is resetting in 2min or 14min. So it does not help my rate limiter to progam the queued calls. Or am I missing something? 

The rate limit usage resets every 15 minute at 0, 15, 30 and 45 minutes after the hour. The daily limit at midnight UTC. This is mentioned in https://developers.strava.com/docs/rate-limits/, but it would be more convenient if this is given some more emphasis.

---

An application’s 15-minute limit is reset at natural 15-minute intervals corresponding to 0, 15, 30 and 45 minutes after the hour. The daily limit resets at midnight UTC.

---

I can confirm that this is happening when I look at responses that our application is receiving.

Ok thank you for this information. I was planning on using Bottleneck as library for rate-limiter (https://www.npmjs.com/package/bottleneck => the reservoir concept in this library). But with this library I cannot set up when the limits gets resetted. The 15min interval starts when the application is launched, I cannot say it should start at 0, 15, 30 and 45min after the hour. Do you advice any other library?

No, sorry. We're on the JVM on the backend here.

We've also found the available RateLimiter implementations, e.g. https://resilience4j.readme.io/docs/ratelimiter to not work for us, so created our own for this purpose.

The advantage was also that we could omit hard limiting the RateLimiter values and can always use the response headers to set and update the limits and usage.

In our case, we perform calls from multiple servers, so we cannot rely on the internal counters of rate limiters and can only trust the values returned in the response headers.

I have found a library allowing me to set and update the limits and usage, and set the reset time of the limits the way I want: https://www.npmjs.com/package/rate-limit-scheduler. I have implemented it, seems to do exactly what I want. Thanks for your help, it seems to be a better implementation of rate limiting than what I was initially planning on