Raffi,
I have noticed that the API sometimes returns user ID's that are out of sync with username. I think one case is where a Alice retweets Bob's tweet, and then Bob changes his name to Charlie. When I try to reply to it, it doesn't show up as "in reply to" to original tweet because the reply contains "@Bob" instead of "@Charlie". It would actually get confusing because a new user could sign up as Bob and kind of "take over" Charlie's old @mentions that contain "@bob". Is this change an attempt to address that, by fixing the screen_name->userid mapping at the time a tweet is created? When we post tweets that include @mentions, can we include our own entities/user_mentions in our request body, so that Twitter can notify us if one of the mentioned screen names has a different userid than what we were expecting and/or one of the mentioned screen names is not a valid screen name anymore? That would be extremely helpful in dealing with this edge case-even if it was subject to some race conditions over a narrow period of time. entities/user_mentions/screen_name and entities/user_mentions/text are redundant. I would rather just pick the text out of the tweet using original tweet text indexed by the indices property, to save bandwidth. Regards, Brian Raffi Krikorian wrote: As part of our JSON and XML payloads, we are going to start supporting an entities attribute that will contain this parsed and structured data. you'll see it like so: { "text" : "hey @raffi tell @noradio to check out http://dev.twitter.com #hot", ... "entities" : { "user_mentions" : [ { "id" : 8285392, "screen_name" : "raffi", "indices" : [4, 9] }, { "id" : 3191321, "screen_name" : "noradio", "indices" : [16, 23] } ], "urls" : [ { "url" : "http://dev.twitter.com", "indices" : [38, 64] }, ], "hashtags" : [ { "text" : "#hot", "indices" : [66, 69] "url" : "http://search.twitter.com/search?q=%23hot" } ] } ... } as shown above, we'll be parsing out all mentioned users, all lists, all included URLs, and all hashtags. in the case of users, we'll provide you their user ID, and for hashtags we'll provide you the query you can run against the search API. and, for all of them, we'll also tell you at what character count the entity starts and stops -- that should really take the burden off you guys to parse the text properly. this entities block will probably be extended later, and these entities are just the start. have we missed anything? is there anything else you would like to see? as always - just drop us a note, and look for these entities to start slowly rolling out.