Apparently sometime yesterday, the endpoint mentioned in the topic stopped honoring the offset parameter. I use it in a script that I run every morning, and it’s been working perfectly for over a year, but this morning I started getting the same list of results no matter what offset I passed in.
Works fine here, but I’d also recommend using the cursor instead to paginate through results.
Don’t know why offset/limit is working for you and not me, but I did just change the script to use cursor pagination instead (fortunately, that’s the only endpoint where I need more than one page of info) and that does work.
The problem I saw on my side is that the “direction” is no longer taken into account.
And that the default is ASC (oldest to newest).
Edit: The problem is also on the side of the new API, it returns the old followers and not the recent ones.
Looks descending to me.
Some “users” do not seem to have this problem (confirmed),
In my testing, I use the following identifier: 100449819
array(3) {
[“_total”]=>
int(1067)
[“_cursor”]=>
string(19) “1454088384552079000”
[“follows”]=>
array(2) {
[0]=>
object(stdClass)#8 (3) {
[“created_at”]=>
string(20) “2016-01-29T17:10:32Z”
[“notifications”]=>
bool(false)
[“user”]=>
object(stdClass)#9 (8) {
…
}
}
[1]=>
object(stdClass)#10 (3) {
[“created_at”]=>
string(20) “2016-01-29T17:26:24Z”
[“notifications”]=>
bool(true)
[“user”]=>
object(stdClass)#11 (8) {
…
}
}
}
}
array(3) {
[“total”]=>
int(1067)
[“data”]=>
array(20) {
[0]=>
array(3) {
[“from_id”]=>
string(8) “95377328”
[“to_id”]=>
string(9) “100449819”
[“followed_at”]=>
string(20) “2016-01-29T17:10:32Z”
}
[1]=>
array(3) {
[“from_id”]=>
string(9) “105170025”
[“to_id”]=>
string(9) “100449819”
[“followed_at”]=>
string(20) “2016-01-29T17:26:24Z”
}
[2]=>
array(3) {
[“from_id”]=>
string(9) “114222928”
[“to_id”]=>
string(9) “100449819”
[“followed_at”]=>
string(20) “2016-01-29T18:42:50Z”
}
[3]=>
array(3) {
[“from_id”]=>
string(9) “114223013”
[“to_id”]=>
string(9) “100449819”
[“followed_at”]=>
string(20) “2016-01-29T18:45:45Z”
}
[4]=>
array(3) {
[“from_id”]=>
string(9) “113822938”
[“to_id”]=>
string(9) “100449819”
[“followed_at”]=>
string(20) “2016-01-29T21:54:03Z”
}
…
[“pagination”]=>
array(1) {
[“cursor”]=>
string(48) “eyJiIjpudWxsLCJhIjoiMTQ2NDcyOTkxMzAzODQ4NTAwMCJ9”
}
}
1 Like
Seeing the same thing here with regards to direction. Default is ascending, and the direction parameter does nothing.
User ID here is 49390072.
OK, I see both issues with that user ID. I’ll poke someone.
1 Like
Should be fixed!
1 Like
It’s even more screwed up now. Specifying a limit of 100 records and no direction, I get one page in ascending order, and a second page that is basically same as the first but in descending order. If I don’t specify a limit, I get one page of 25 records in descending order. With a page size of 25 records, I should be getting 12 of them.
Some of the responses could still be cached from before the fix. I’ll let the team fixing it know if it continues…
How long should it take for the cached responses to expire? The script will run again automatically at 4:15am EDT tomorrow, and I’ll get a report of that, but I can try again before then if I know how long to wait.
Fixed on my side, Thanks ! 
1 Like
Yep, working here now too. Thanks for the fix.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.