Users/lookup just returning 1 user, asked for 100


We have not changed any of our code (it’s been running since 1.1 came out) and have employed a scale down system that tries to fetch 100 user details through “users/lookup”, if it times out, scales down to 50 users, if not, scales down to 1 user, etc. – Once things work again, it scales up back to 100.

Since a few days ago, we only receive 1 result, constantly. This completely burns our rate limit (180 users per window, instead of up to 100 x 180 users).

Is there something faulty with the endpoint, or has it changed? We also see a lot of invalid IDs … dead accounts… What’s up?

Please advise, we’re having thousands of paying customers on our end waiting for a fix.


I’ve just verified this, it seems to relate to a change in Twitter’s response handler.

If I just process one account, and reduce the number of IDs requested to 50, then I’ll receive between 1 and 3 hydrated user objects. Requesting with 100 IDs, always delivers just 1 hydrated user object.

What’s going on guys? @episod any ideas?


Can you provide some example requests that demonstrate this behaviour?


I to can replicate this problem. To add to it, if any one of the list fails, no matter what order the accounts are in, I get an error returned and no actual data.

I am doing this looking up via screen_name


Hello Andy, thanks for taking this on.

One user I am seeing this problem with has the ID: 57497901

I then call: with include_entities=false and user_id set to the following:


This responds with just 1 user object, with the ID: 545755653


I was able to identify the bug on our end and now understand the issue better:

What happened was this:
When some of those IDs sent to users/lookup are invalid (dead accounts), you don’t receive details on them back. We ran into cases where we had large amounts of such IDs piling up, so each call had one follower in there that did work, the others were being carried forward. Up to a point where we were just sending calls that had no response.

I guess there isn’t anything Twitter can do about this, it’s just sad that a lot of those accounts might be there in the database from a scan yesterday and today, they’re burning up costly calls in the rate limits until we get through that to more valid IDs then.

Alright, I think you can close this, not sure why this has never been an issue in the past year, seeing it for the first time now.



ok, this is useful feedback anyway - appreciate the level of detail!