Example of being able to look up a user by user_id but not by screen_name:
curl "https://api.twitter.com/1/users/lookup.json?user_id=343752773&include_entities=true"
(success, with user object containing screen_name = "RonForrestRon")
curl "https://api.twitter.com/1/users/lookup.json?screen_name=RonForrestRon&include_entities=true"
{"errors":[{"code":17,"message":"No user matches for specified terms"}]}
Other known issues with users/lookup:
* Occasionally a look up for a user by screen_name returns a user object for a different user -- often a user who was mentioned by the looked up user. Requesting include_entities=true may effect this result as well.
* Asking for a set of IDs can result in getting a user not in the requested ID set.
Currently suspected to be a cache pollution issue.
Updates
- 2011-11-30: Accepting the issue, but widening it to general cache consistency issues with user objects and combining it with other known issues.
- 2012-02-08: The cause of requesting a lookup by one user ID and getting another user ID in return has been identified and should be fixed within about a week.
- 2012-02-15: The fix for the "request one user and get another" issue has been deployed, which has likely addressed a few cache pollution issues. Please let us know in the discussion group if you see any further problems and we will reopen if needed.