Why favorited is always false in twitter search api 1.1?


I am using twitter REST api /search/tweets.json it respond with JSON of tweets against my query but the Favorited field is always false. When i use /statuses/show/{id}.json api to fetch that particular tweet it give me correct value for Favorited attribute unlike search API which always returns false.
Is this is the way it is according to twitter or is there is something i am missing ? To me it look like a inconsistent data issue
I have checked it on https://apigee.com as well as using twitter4j
Thank you for reading my post :wink:


Hey, this is currently a known thing, and as far as I know it is not planned to change this. (Seems this isn’t very easy to fix?)
The favorited and retweeted fields are always false for Tweet entities returned by the search API.


You could just do a simple test to see if the retweet_count/favorite_count are > 0 to get the same information. They seem to be correct in the search API. I imagine that is why it’s a low priority to fix this issue, as the correct information is otherwise contained, and easy to extract.




Actually you are not completely correct. The information if there are ReTweets and Favorites says nothing about the retweeted or favorited fields, as these fields indicate if the authenticated User has faved or RTed this Tweet, not if anyone else has.


@ePirat i am searching with authenticated user and it is still 0 in both cases, as i said earlier that when i uses /statuses/show/{id}.json API i get correct value of favorited and retweeted based upon user that user


Yeah, as I already said:

The favorited and retweeted fields are always false for Tweet entities returned by the search API.

This is a known issue of the search API unfortunately. It would be great to get some Info from Twitter if this will be fixed some day.


Ahh, of course. I misinterpreted both the OP requirements and the intention of those fields. I’ve never actually used those ones in particular (through REST or search API), so wasn’t aware of the connection to the authenticating user.

However given that, as a work around, this would still allow you to make less secondary requests to the REST API to see if the authenticating user had retweeted/favorited them. As if those values are zero, then no one, including the authenticating user will have retweeted/faved them, so you don’t need to check them. Also given the ability to bulk lookup of statuses (up to 100 at a time) this could mean as little as one more API request to work around this problem. Just a bit more code complexity.

I can now understand why this functionality is difficult to implement in the search API. Because it is one big generic index (suitable for any authenticating user), it would be relatively resource intensive, and slow down responses from the search API, if they had to do secondary lookups for every returned tweet against the authenticating user, to fill in fields such as these. The data even though retrieved by an authenticating user is equivalent to that an anonymous user might get (if they could). It is perhaps a similar reason also why protected tweets aren’t indexed, because there is no secondary filtering/update of the data based upon the authenticating user.




Yeah exactly. What I would recommend (depending on the usecase) is to cache a reasonable amount of ReTweeted Tweet IDs and Favorited Tweet IDs, so that the app can identify at least some recently favorited/retweeted Tweets when showing search results.
Given that the search endpoint doesn’t return Tweets older then some weeks, this for most cases works out quite well.