0
votes

According to documentation: https://www.instagram.com/developer/limits/

The rate-limit control works under a "time-sliding" window, the question is:

What's the frequency of increasing for the remaining calls HTTP header (x-ratelimit-remaining) seconds? minutes?, an hour?

Reading the docs. "5000/hr per token for Live apps" (our company App went Live already), I assumed a frequency limiter, being calculated each second or minute, but after several days trying different strategies the value doesnt seem to have any deductible behaviour.

Possible answers (depending how it is coded) could be:

(a sliding window like a frequency limiter)

  • it increases 1 credit each 720 ms (3600'(1hr) / 5000 (remaining calls)) without a request until reaching 5000, it decays to 0 otherwise. If we do 1 req. at the correct frequency, we should never lose 5000 calls., So we could spend them strategically: dispersed, cluttered, traffic-adapted.

(a limited sink recharging each hour)

  • with 5000 remaining, it decays 1 credit per request -no matter the frequency-, after 1 hour passed since that 1st request: it goes back to 5000

  • it renews to 5000 each 1 hour counting since the token was used to do the 1st request.

  • it decays 1 credit per request, and it goes to 5000 in a time fixed hour, like at 12:00, 13:00, 14:00, 15:00...

I'm using jInstagram 1.1.7.

1

1 Answers

0
votes

After a lot of testing.... I have some temporary conclusions...

Starting from 5000, if you fetch at uniform rate (720ms/req) you will reach 500 like at the minute 50, then instagram will begin to give you credit in portions lesser than 500. So at the minute 60 you'll have 150 remaining calls left, and instagram will give you another credit portion, generally reaching 500 avg. and going down again of course...

If you stop consuming, like 30 minutes aprox. You will acquire again 5000 credits.

Also they give you 5000 remaining calls, they seem to have counters indexed by IP, if you make the request from different IPs with the same credential, they'll act like ignoring the others.

Besides that, instagram have many errors keeping a consistent value for the x-ratelimit-remaining HTTP header they respond on every HTTP request. It looks related to some overriding, and some kind of race between the servers replicating the last value.

Shame on you instagram, I spent a lot of time adapting my cool throttling algorithm to your buggy behaviour, assuming you had good engineering down there !

Please fix them so we can play fair with you instead of playing hide and seek, stealth tricks..