Favorites/list endpoint not returning correct # of tweets

[Danny__Garcia]

According to the documentation for the Favorites/list REST API endpoint, you’re allowed to ask for a maximum of 200 tweets using the count parameter.

I have a user with over 1,000 favorited tweets. When I make the first request for the first 200 favorited tweets, I get back 200 tweets. EX: https://api.twitter.com/1.1/favorites/list.json?count=200

Everything works fine up until this point. However, when I make a subsequent request and ask for the next 200 favorited tweets, twitter returns 199 tweets instead of 200. Looks like twitter is breaking their API contract.

The method by which I ask for the next 200 tweets in the second request is as follows:

1. I grab the id of the last tweet in the array response from the first request.

2. I use the id from step 1 as the max_id in the second request. The max_id specifies that you want tweets that are older than or equal to the specified id. This is an optional parameter that can be passed into the request.

Here’s what the second request looks like:

https://api.twitter.com/1.1/favorites/list.json?count=200&max_id=id_of_last_tweet_from_first_response

Because this user has over 1,000 favorited tweets, and the first request only grabbed the first 200, this second request should be returning the next 200 tweets. The actual behavior is that the twitter API is returning 199 tweets in the response.

I am testing this by using twitter’s OAuth Tool to create a CURL command with the appropriate OAuth signature, then piping the response to a .json file. I’m then parsing the JSON and counting the number of tweets in the array.

Can anyone provide insight on this issue? How do we contact twitter about a potential bug in their API?

UPDATE
After further testing I’ve noticed that twitter sometimes also returns 199 tweets instead of 200 in the first response. When asking for 200 favorited tweets in the first request, even though there are well over 200 tweets.

[abraham]

The value of count is best thought of as a limit to the number of tweets to return because suspended or deleted content is removed after the count has been applied.

The count value is not guaranteed. It is more a max limit with best effort to match the number. If you have to have 200, you will have to paginate for the next collection to fill in the remaining number.

[Danny__Garcia]

Thanks a lot, this clears things up for me.

What I’m trying to do is allow users to request all their favorited tweets upon account creation, and later request for newly-favorited tweets. My logic was that if I ask for 200 tweets and get back any number less than 200 then there must not be any more favorites to make an HTTP request for. If I do get back 200 tweets, then maybe there are more favorited tweets that I should request for.

On account creation, when wanting to get all of a user’s favorited tweets, I don’t see any data that provides the number of tweets that are remaining that are older than the max_id supplied.

And when later requesting newly-created favorites, I don’t see any data that provides the number of tweets that are remaining that are more recent than the since_id supplied.

I can already think of ways to go about solving this, though they seem a little hacky. I know this is unrelated but if you have any insight on how to go about doing this, I’d greatly appreciate it.

[abraham]

Working with TImelines has some guidelines for working with since_id/max_id. In general I would recommend going in whichever direction you want until you get an empty response with no tweets. Although you should probably have a total max to avoid getting in an infinite loop if Twitter happens to keep returning one tweet.

[Danny__Garcia]

Perfect, this should work. I hadn’t noticed that there was documentation for working with timelines. I appreciate your help.

[ashtekarmukesh]

Hi Danny, I am also getting 199 tweets. Have you found any solution ?

[Danny__Garcia]

Working with TImelines

Yup, this helped. https://dev.twitter.com/rest/public/timelines