Is there a time line for the streaming API getting these changes?

Zac Bowling

On Mon, Aug 23, 2010 at 11:40 PM, Matt Harris <> wrote:
> 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,
> Matt
> On Sat, Aug 21, 2010 at 4:33 PM, Joe <> wrote:
>> will we see this in both search and stream API?
>> On Aug 20, 6:45 pm, Matt Harris <> 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 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, Twitter
> --
> Matt Harris
> Developer Advocate, Twitter

Reply via email to