Hi Developers,
Beginning January 31st, 2012 the Twitter REST API will begin uncapping the retweet_count field on tweet objects returned on tweet-bearing methods such as GET statuses/show/:id, GET statuses/home_timeline, and GET statuses/user_timeline.
Instead of having a string representation take the place of an integer when the retweet_count exceeds 100, the count will reflect the actual number of times the tweet was retweeted as an integer. With the exception of the occasional cached tweet object, the "100+" string value will become an artifact of the past.
Please let us know if you anticipate any issues with your applications due to this change.
Thanks!
@episod
Replies
I anticipate that this will be great for us!
I have to agree on that one, on the other hand a LKI string (as an oldie calls it like me) can fix many of those particular problems with the timeline
This is great news! Just out of curiosity, is the favorite count also capped? If so, will it be uncapped at some time in the future?
Right now, favourites_count is a field attached to users describing how many tweet they've favorited. It is uncapped, but had an artificial cap in the past. However, even though it is uncapped, it's not always completely accurate due to the particular implementation -- however, they tend to be close enough and we have an ultimate goal of improving their accuracy over time.
There's also an accounting for per-tweet favorites in the upcoming Activity API (a version of which you can see on Twitter.com today) -- those counts are determined a bit differently than these fields, and its unclear whether the future API will provide raw counts.
will this change also be reflected on tweet pages on Twitter.com?
Likely, though I can't speak for the site and whether the timing will be simultaneous.
Thanks!
will a _str variable be provided incase the count is higher than 32bit? ;)
This has been suggested and may be accounted for in the future. However, for the time being you should be safe consuming the integer. Code defensively for the time being :)
Admit it, you are doing this after that blog post http://gazit.me/2012/01/09/Twitter-documentation-fail.html :P
lol. I have the same feeling.
Cool
thanks
Good news!
Will this also apply to the streaming API at the same time, or are there plans to uncap the counts there at a later point? Thanks!
Hi @PanMan,
This change will be reflected in the Streaming API as well.
Taylor, this is great news. Any chance the (uncapped) number of retweets will also be included in search results?
Uncapped counts are already presented for Search results of result_type=popular but will not likely make it into the current version of the Search API for all results.
Great news. We were following the action of the presidential candidates and the 100+ cap made it almost impossible to see the real engagement.
Tracking tweets as they happen with the Streaming API will always be the best way to count things such as retweets.
I think tracking tweets as they happen with the Streaming API will be a great idea
Is this still scheduled to be deployed today? (Jan 31st, 2012)
Yes, it is. We'll announce from @twitterapi and in this thread when the switch is flipped. Likely will happen around noon Pacific time today.
Thanks Taylor.
This announcement fills me with joy. More like this, please.
A little late, but we're beginning this change now.
This is now rolled out.
Keep in mind that cached representations of tweets will not reflect this update until their cache rolls over.
You can see some of the new >100 integer retweet_count fields in the wild by monitoring the sample stream for retweet_count fields.
Thanks all!
Do I have to keep checking retweet_count for a tweet to get the final count? What's the best way to get the final retweet_count number for a tweet or list of tweets?
There will never be a final retweet_count for a status -- tweets live
effectively forever and can potentially have as many retweets as there
have been Twitter users.
Monitoring the retweet count for a status could probably be better
accomplished with the streaming API...
If I want to track the retweet_count for a @justinbieber tweet, how would I use the streaming API in this example?
The easiest way would be to track all tweets by @justinbieber which would include retweets of his Tweets.
First you would look up his user ID with the REST API: https://api.twitter.com/1/users/show.json?screen_name=justinbieber (It's 27260086).
Then track his tweets with the streaming API's statuses/filter with follow parameter.. here's an example using basic auth and curl on the command-line
curl -u user:password "https://stream.twitter.com/1/statuses/filter.json?follow=27260086"
As you consume that response, you'll watch for @justinbieber's tweets with the retweeted_status node and from there winnow down in your processing code to the specific tweet IDs you're interested in.
We just built this little tool to check the top 10 most retweeted tweets of any Twitter account.
Here's the results for @twitterapi http://mytoptweet.com/?u=twitterapi
... and http://mytoptweet.com/?u=ladygaga and so on.
It looks like this is still not enabled in the streaming API if you filter by a bbox. Try it outside of the US and you'll see.
Come to think of it...It actually does make sense that there are no retweets coming off the Streaming API. https://stream.twitter.com/1/statuses/filter.json?locations=-122.75,36.8,-121.75,37.8 seeing at they are happening in real time ;-)
Yep :) You'll need to count manually or fetch count later by using the REST API.
It would be great if one could get a favourites_count field in every tweet as the number of users having faved a certain tweet!
Great idea!
loogoolz
One of the best.
http://a0.twimg.com/profile_images/1124040897/at-twitter_normal.png",