The pagination returned by the new unban_requests API seems wrong


It’s been a long time since I posted a topic :smiley:
Feedback from the new API in beta GET helix/moderation/unban_requests

I have been using it since it was made available in the following way: I created an interface which allows me to process each deban request for a streamer, in a slightly more role play way. It’s a kind of court that will allow the streamer to judge each ban call by providing him with the information we have on the user (messages, previous timeouts, whatchtime, etc.)

In this context I use this last API by providing it, at the beginning only with the field first = 1/status = pending, to have one case at a time.

When we move on to the next case, I use the pagination cursor to provide it to the query. So I send the same API call as previous but with after = previous cursor.

It works very well, let’s say at the beginning… after a while, and I noticed from 30 cases, without the delay having anything to do with it, the API starts to send me empty data, while continuing to give me cursors…


While I continue to provide it and I make the calls… and after a moment, magically, I have the following recording (which is indeed the one which should have been given to me from the start).


In the same way when I theoretically arrive at the last deban request in pending status (around forty, easy to check with the call without first parameter), the API continues to send me cursors for the next pagination…

My theory is that there is a bug which means that the pagination does not apply to the data filtered by the status but continues as if there was none, but that when I send the data back of the recording, so having filtered everything that is not pending, there is nothing left in the response body.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.