Get twitter friends usernames



Hi I notice that twitter has the useful function GET friends/ids, what if you want instead a friends screen_name. Screen_name’s are used instead of IDs in many function calls, so it would be useful to get them in a list like the IDs. Do you have to use GET friends/list which returns loads of information of only 20 friends? I suppose you can get the IDs and then look up info for each ID but then that is many API calls.




You can a use the users/lookup endpoint to get the user data. Most endpoints do allow user ID or screen name though I know what you mean. The only problem you may run into is that the users lookup endpoint has a lower limit (100) than the number of ids that you may get (up to 5,000).


I have found that it is possible to get 200 friends using the friends/list method (max 3000 per 15 mins) but it is still much less than the 5000 IDs that are possible in one API call (75000 per 15 mins). The users/lookup function is useful as it allows 180 calls for the user so that’s a potential 18000 users, but that’s a lot of API calls!

Oh why is the Twitter Rest API so inconsistent?!


One of the main use cases for GET friends/ids is to provide a performant method of keeping users friend graphs up to date. user_ids are the source of truth for identifying users since their screen_names can change at anytime.

Screen_name’s are used instead of IDs in many function calls

What API methods require screen_names? Other than within the contents of a tweet I think you should be able to use user_id just about everywhere.


Well they don’t require a screen_name but they are optional and can be used instead of ID’s in most API calls, this is why I choose to use them other than IDs (I would still have the hassle of getting screen_names for IDs anyway). Screen_name’s are more useful to use in an application for the user as users have no way of making sense of ID number as they can with a screen_name. Thanks for pointing out about users changing the screen_name must remember that and account for it.

There are 4 basic bits of information required of a user, would be nice to have a way of getting this basic information

[[id][screen_name][display name][name][profile_image_url], … ]

also would be nice to mention which list the user belongs to as well


Personally I just cache the user data for ids. So if I go to get the list of friends, I check my system for ids I’m missing, fetch them. If my data is older than x day, I fetch and update.

[Edit] Plus that lets me possibly query the data is more ways too.


Not a bad idea, but the user data could get out of date (I suppose you manage this with updating after X days) just not sure of the server memory requirements of caching large amounts of user data for days at a time, plus you have to do it all at the beginning for new users and after X days anyway.


BTW GET friends/list supports count=200 so you can get 200 user objects for each request.

Many of these APIs can be combined for different combinations of number of requests optimizations vs freshness and accuracy of data. A reasonably efficient approach would look something like this:

  1. Use GET friends/lists to iterate all current friends and get full user objects
  2. Some time passes
  3. Use GET friends/ids to get a snapshot of the user’s current friends ids
  4. Compare those ids with the existing full user objects you have and keep a list of new ids
  5. Use GET users/lookup with the list of new ids to get full user objects

On those full user objects you could store the data the user object was cached and then run periodic updates to refresh them as you need.


Just wondering how you are going about your caching, do you store on disk or in memory or on file, do you use a timeout for the user data, APC, or some kind of database? I like the simple approach, but maybe its not possible for me to avoid doing user data caching, but hey I could HTML5 local storage in the browser.


I store it in mysql.


What do you do about inactive users filling up your DB for nothing?


Figure out which ones are for nothing and remove them after x time. My table is relatively small, I only car3 about like 7 fields and 2 are integers and one big int (user id). Million rows take up under a gig, even indexed.


Ok, Thanks for your help,

I guess the average twitter user only has ~200 followers, but then again maybe these are not the ones who would be interested in productivity apps


What would be cool is if Twitter returned a last date updated when you get the the friends ids (GET friends/ids), then this date could be used to get new user information in the case of the user data being out of date (compared with when you last got their data). Otherwise the only way you can check for updated data is to get the full users data even if you need it or not (and how do you ensure that the data is current - if you do it every week then it can be out of date by a week - if you want it to be current then maybe you have to get all user data every minute or so!) or you could always keep an inaccurate copy of your user data regardless (this is maybe the more practical but not optimal solution).