Max_id in search api is coming same after every pagination

[07_vivek_dev]

I’m getting the same max_id in every pagination across the search api 1.1

[JohnTCuriOus]

The same here…

I know there are more results cause after running queries for count=100 I run it for count=2.

I’m using search_metadata.max_id_str substracted by 1 when building URL for the “prev” page. My logs:

14:27:40.473 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&count=3&q=blue&include_entities=false
14:27:40.986 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&max_id=473440748193738751&count=3&q=blue&include_entities=false
14:27:41.780 Returned max_id is the same as previous one! PREV:473440748193738751, RES: max_id=473440748193738751, max_id_str=473440748193738751
14:27:41.781 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&max_id=473440748193738750&count=3&q=blue&include_entities=false
14:27:42.613 Returned max_id is the same as previous one! PREV:473440748193738750, RES: max_id=473440748193738750, max_id_str=473440748193738750
14:27:42.613 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&max_id=473440748193738749&count=3&q=blue&include_entities=false
14:27:43.454 Returned max_id is the same as previous one! PREV:473440748193738749, RES: max_id=473440748193738749, max_id_str=473440748193738749
14:27:43.454 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&max_id=473440748193738748&count=3&q=blue&include_entities=false
14:27:44.475 Returned max_id is the same as previous one! PREV:473440748193738748, RES: max_id=473440748193738748, max_id_str=473440748193738748
14:27:44.476 sending request: URI=https://api.twitter.com/1.1/search/tweets.json?result_type=recent&max_id=473440748193738747&count=3&q=blue&include_entities=false
14:27:45.348 Returned max_id is the same as previous one! PREV:473440748193738747, RES: max_id=473440748193738747, max_id_str=473440748193738747
[…]

[JohnTCuriOus]

Wow, and sometimes returned values of max_id and max_id_str are not the same :o

search_metadata: {
completed_in: 0.077
max_id: 473481617038929900
max_id_str: "473481617038929920"
next_results: "?max_id=473479251598274559&q=tweeter&count=100&result_type=recent"
query: "tweeter"
refresh_url: "?since_id=473481617038929920&q=tweeter&result_type=recent"
count: 100
since_id: 0
since_id_str: “0”
}

[JohnTCuriOus]

As I wrote before (but it wasn’t published (yet?)) I have the same problem… Returned max_id is the same as max_id given as query/get param.

[joelmilne]

This thread is a bit old, but I was having the same issue so will leave the solution here for future reference.

First off, returned values of max_id and max_id_str are different in languages that can’t handle 64 bit integers (e.g. Javascript). In this case use max_id_str. This is well documented.

More importantly, why is max_id_str the same for every page in the search? Because you are not supposed to use max_id_str as the parameter for the next page. max_id_str is the value of the greatest id in the current search results. This value on the first page of results can be used for the since_id_str parameter for future searches. If you want the next page of results, you must a) either calculate the min id_str in the current result set (and subtract 1 if you have a language that can deal with 64 bit integers to avoid a duplicate), or b) you can parse the next_results field and get the max_id from there and use that to get the next page of results. It’s super annoying they don’t just provide min_id_str for the current results, to be used to get the next page, but that’s what it is. This sample code cleared it up for me:

Twython search API with next_results

[andypiper]