Users/lookup not returning data with comma seperated query parameter for screen_name



I am looking for some assistance or clarification on how to properly form my query to pull data on multiple screen names using users/lookup. In the documentation, it says the query parameter screen_name can contain a comma-separated list to return multiple users. User/lookup documentation

However, when I attempt to hit this endpoint,cavs

“message”:“Could not authenticate you.”

When passing a single parameter (e.g. MiamiHEAT), the data pulls properly. Additionally, if I use ‘&’ to add an additional parameter, such as:

The data is returned without issue.

Am I missing something? Also, it states in the documentation that a POST is strongly recommended for pulling multiple usernames, but there is not POST documentation on users/lookup. Can someone please clarify this?

Thanks in advance for the help.


I’m not able to test at the momentime but I think you may need to Url encode the request.

As far as the POST part of your question. All the information is the same, they just recommend sending it as a post instead of a get because if the screen names are long enough the request will be rejects as a get.


I’ve just issued the same request (the first one) using twurl and it responds with both user objects as expected. Using twurl -t to trace the request, I see that the comma character has indeed been URL encoded (to %2C) which enables the request to work.

As @DanielCHood mentions, the reason for suggesting POST here is that you won’t be limited by the length of the URL query string. I will see what we can do to clarify this in the documentation since it doesn’t seem to be clear enough at present.


Perhaps this could be further clarified? At the moment, the documentation states “up to 100 [user ids] are allowed in a single request. You are strongly encouraged to use a POST for larger requests.” Does the “larger” in this sentence mean “larger than 100”? Or does it mean large in a more generic way?


That’s a great question and I take that on board. It refers to “larger” in a non-specific context. We should make the query length clearer. I’d generally encourage a POST request as you get into the 25+ range to save the query parameters breaking at an HTTP level especially with full Snowflake ID numbers.


While developing twiter-lite, I’ve specifically tested GET requests to users/lookup, with 100 user IDs of 18 characters each. They worked fine.

What is the exact limit for URL length, and where is it imposed?


It can vary between the HTTP server and client library you’re using, depending on your language choice. If GET works for you, then that’s great. This is just a potential tripping point for some programming environments.

closed #8