Twitter API Consulting
140dev@gmail.com
781-879-2960
@140dev

Engagement Programming: Best practices for collecting user account info

by Adam Green on November 29, 2013

in Engagement Programming

The Twitter API provides two requests for user account info: users/show and users/lookup. On the surface the difference between the two seems obvious. Users/lookup returns data on 100 accounts at a time, while users/show only delivers a single user. The Twitter docs make the correct suggestion that users/lookup is best suited for gathering the account info based on a list of user_ids returned by requests like friends/ids and followers/ids. This leaves out an important difference between the possible requests.

Users/lookup only returns accounts that have not been deleted or suspended. If you pass 100 user_ids to this API call, and 10 of them are either deleted or suspended, you only get back data on 90 user accounts. It is up to you to compare the accounts returned with the accounts requested, and decide how to deal with any that are missing from the results. The problem with this is that you can’t tell which of the missing accounts are deleted or suspended. If an account has been suspended, it will almost certainly become active again in a few days. You may want to save the user_id and try again later to get its data.

Users/show, on the other hand, always returns something when a request is made. If the account is valid, you get the full profile. A 404 error code is returned for deleted accounts, and 403 is returned for suspended users. This makes users/show more informative, but rate limits and performance delays from making multiple requests makes it impractical as a replacement for users/lookup.

I’ve developed a set of best practices for handling this situation:

  • When gathering data on a list of friends or followers, I first run users/lookup as my first pass. If any user_ids do not return results, I put them into a table along with the date/time of the first lookup. I then process this table’s contents with users/show. The user_ids that return a 404 are removed from the list. I repeat this processing every 24 hours. The suspended users will eventually reappear, and their ids can be then be removed from this list.
  • I also maintain lists of users that need to be updated regularly for applications like tweet display or suggested follows. I add a date/time field to these user tables that is updated whenever I get a new copy of the account profile. Users/lookup is run against this list every 24 hours or so. If an account hasn’t been updated for 24 hours, I test it with users/show. Deleted accounts are removed, and suspended accounts are left in place, but flagged as suspended to keep them from being displayed by my apps.

You can find examples of this type of programming in the source code for my engagement programming book.

Leave a Comment

Previous post:

Next post: