X-ratelimit-remaining returns wrong number

Tokens, ratelimits, quotas & registration
1

Hi there,

I’m trying to use the HTTP headers x-ratelimit-remaining to figure out how many calls I have left every day.

I’m doing a Matrix V2 call with 1 origin and a little over 150 destinations.

After doing 1 call, my dashboard correctly displays 499/500 remaining
The HTTP header of the CURL return however, returned [x-ratelimit-remaining] [0] = 0

After the 2nd call, the dashboard correctly displays 498/500, but the HTTP header returns:
[x-ratelimit-remaining] [0] = 466

And after the 3rd call, the HTTP header returns [x-ratelimit-remaining] [0] = 445.

After the 4th call, it was finally correctly returning 496.

But after the 5th call, it returned 445 again (!).

Can anyone please explain what is going on, and how to get the correct amount of matrix v2 calls remaining?

Thanks!

Laurens

2

Hi @Destiny,

This is a known issue. The x-ratelimit-remaining header is a bit volatile.
Hopefully this will be fixed once we updated Tyk to the latest version in the next weeks.

Until then you will either have to user the dashboard to see your exact remaining numbers, or e.g. make calls until 429 status is returned.

Best regards

3

Hi Amandus, thanks for the reply.

Could you then tell me how I can figure out at what time of the day my quota reset?
I read in another topic this is the time of first use.
But I don’t recall the exact time I made the first call.

Is there any way for me to see this, so I can at least reliably keep track of the amount of calls I make daily myself?

Thanks,

Laurens

4

Hi again,

It’s pretty much the same for the x-ratelimit-reset header.
It currently doesn’t work properly. It will probably also be fixed with the update, but not sure on this.

I just tested and sometimes it even shows a correct timestamp, but it seems far from reliable.

Sorry, but there is currently no way around either implementing the daily limits yourself (only run allowed request amount, repeat after 24h.) or catching the rate-limit exceeded status (429).

Best regards

5

Update:
while the x-ratelimit-reset header still shows wrong timestamps in some cases.
The x-ratelimit-remaining headers seems to work as expected now (from some basic testing to directions and geocoding enpoints. Not tested on all endpoints!).

If you are still encountering issues for the remaining ratelimit, please update this topic.