Cant get real rate_limit_status

[OscarClar1]

ill trying a simple request, taht works fine: but all time shows me 15 remaining , when i refresh 15 times rate limits error pop up

Any idea? thanks

<?php

//CARGAMOS DATOS DE API
include_once ("ckey.php");	

$accesstoken = "xxxx"; 
$accesstokensecret = "xxxx";

//CARGAMOS LIBRERIAS
use Abraham\TwitterOAuth\TwitterOAuth;       
require "twitteroauth/autoloader.php";

//CONSULTA
$id = 1; 
$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $accesstoken, $accesstokensecret);
$string = $connection->get("trends/place", array( "id" => $id));

$string2 = $connection->get("application/rate_limit_status");

echo "<PRE>";
print_r($string);
echo "</PRE>";
echo " ***********************<br/>";
echo "<PRE>";
print_r($string2['resources']['trends']);
echo "</PRE>";

?>

[MrBrandwood]

I’m having the same issue using code that hasn’t changed and has been working fine for weeks. My code returns the remaining count and reset date for a given resource. For the past couple of days, the remaining value and reset date remain unchanged, even when I’m carrying out requests. As the OP says, I will still hit the limit and get the rate exceeded error, but the remaining count and reset date do not change. Very strange!

Any ideas?

[shalalala]

Facing the same issue here: R code that worked fine for weeks suddenly stopped working on April 3rd.

I now always get 15 or 180 remaining calls when I ask application/rate_limit_status, even though I do get throttled after that many hits. Tried three different R packages, same results: it’s now impossible to get API limits in R.

Workaround: I’m now counting errors and sleeping 15 minutes when I get 3+ consecutive errors.

[ePirat]

Please indent code lines with 4 spaces so they display properly.

Regarding the issues, please have a look if the headers returned contain the right rate limit information as they are better for your usecase I think.

[MrBrandwood]

So is the consensus that this is a bug and it will be fixed - or is it the result of a purposeful change and will continue to ‘misreport’ - or is it an error with our code?

I’ve just simulate the same scenario using the Twitter API Console. The same response is returned there too - so I don’t think it is a problem with our code. I’m therefore guessing it is a problem with https://api.twitter.com/1.1/application/rate_limit_status.json

How can we bring this to Twitter’s attention for clarification?

[MrBrandwood]

I’ve tweeted @twitterapi to see if they will take a look

[ePirat]

Maybe @andypiper can provide a bit more information. I was not able to reproduce the problem, works fine for me here, but this sounds like it is an issue with the application/rate_limit_status endpoint that should be fixed.

[OscarClar1]

Yes, Must be a rare problem, ill try with header rate limits like abraham recomended me, and i can work until problem be resolved

[andypiper]

I’d like to clarify with those on this thread whether this is definitely changed behaviour?

Per the rate limit overview docs:

Ensure that you inspect these headers, as they provide pertinent data on where your application is at for a given rate limit on the method that you just utilized.

i.e. the best way of checking is to keep a running check in the headers for the individual API endpoint calls.

I’ll certainly see what I can find out about whether a change has been made to the behaviour of the values on application/rate_limit_status.

[MrBrandwood]

Well, just tried my code again and it is working as it did originally (i.e., reporting the remaining limit checks correctly)! Very strange. I’m happy but it’s odd behaviour for sure.