Hey everyone,

Thanks for the questions. I'll try and answer them all in this message.

1) are the counts turned on?
This weekend the counts were turned off and have remained off. This is
because of some bugs we found in the way the value was calculated.
I'll let you know when we have this resolved.

2) Will these fields show up in the Search and Streaming API?
The fields are already in the Streaming API but be aware the
'retweeted' field is not meaningful here. This is because the streamed
status knows nothing of the connected user.
The search API does not include this information.

3) How do I know if the feature is turned off?
Tweets will contain a retweeted_count if available. If the service is
not enabled newer Tweets will likely be missing their retweeted_count.
The safest thing to do is code to handle missing values. If they are
present use them, if they are not, treat them the same as when the
field didn't exist. This way your code works when the retweeted_count
is both enabled and disabled.

4) When was the feature turned on?
The service was rolled out the week beginning Aug 16th

Hope that answers your questions,

On Sat, Aug 21, 2010 at 4:33 PM, Joe <j...@ajcomputers.com> wrote:
> will we see this in both search and stream API?
> On Aug 20, 6:45 pm, Matt Harris <thematthar...@twitter.com> wrote:
>> Hey everyone,
>> This week we rolled out a couple of new data fields for the status and user
>> objects. For a while it has been difficult for you to get the number of
>> lists a user is listed in, or the number of times a Tweet has been
>> retweeted. You were also finding it hard to know if the user had retweeted
>> the status themselves or not. The feature requests you filed and the
>> messages on the developer mailing list showed this is a pain point for many
>> of you as it uses up many of your hourly API requests.
>> These fields are live now and many of you have already seen them in our API
>> responses. We intended to tell you about these changes before they were
>> live, and in the future for things like this we will, but this time around
>> our system for doing that didn't work. The good news is we know what went
>> wrong and have made the necessary improvements needed to ensure you are
>> notified before the changes happen.
>> The recent changes which have been made affect the user and status objects.
>> In both cases we have added fields:
>> To the user object:
>> ---------------------------
>> listed_count
>> represents the number of public lists a user is listed in. This field is an
>> integer. As this is a new field it is possible some users will not have a
>> listed_count value yet.
>> follow_request_sent
>> representing whether the user you are authenticating as has requested to
>> follow the user you are viewing. This will be false unless the friendship
>> request is pending. The field is a boolean and will be true or false.
>> To the status object:
>> -----------------------------
>> retweet_count
>> represents the number of times a status has been retweeted using the Twitter
>> retweet action. This field is an integer. There will not be a value for this
>> field when the feature is turned off, or the Tweet was created before we
>> added retweet_count support.
>> retweeted
>> represents whether the user you are authenticating as has retweeted this
>> status or not. The field is a boolean and can be true or false.
>> Changes to existing methods
>> ------------------------------------------
>> users/show
>> When requesting data for suspended users the user/show used to return an
>> HTTP 404 status code - it now returns HTTP 403.
>> This change is in response to number of users who were asking if there was a
>> way to know if a user they were getting data for had been deleted or was
>> instead suspended. The change means the API agrees with the twitter.com in
>> that we confirm a user exists, but that you may not see their information
>> because they are suspended.
>> If you call /users/show on a suspended user the API response will include
>> the error message "User has been suspended."
>> Please remember we sometimes turn features off to maintain site stability.
>> We recommend you always check a field exists before attempting to use it and
>> be prepared for the value to be empty. This will help ensure your code stays
>> stable if we have to turn features off. We'll also be adding this
>> information to the main API documentation soon.
>> Best,
>> Matt Harris
>> Developer Advocate, Twitterhttp://twitter.com/themattharris


Matt Harris
Developer Advocate, Twitter

Reply via email to