Get Streams - Inconsistent response using "first" parameter

GET https://api.twitch.tv/helix/streams?game_id=516575&first=100

If I make the above request I’m getting a somewhat inconsistent response. Sometimes it returns 100, sometimes 99, 98 or even 97. Even though there’s 100+ results. Even if I set it to &first=50 it will sometimes return 49 or 48 for example.

Is this normal behaviour? And is there a way to ensure I always get 100 results exactly?

Did this recently start happening or has it always done this.

It may be related to

I’ve been trying to get this to work for a couple of days now.

I want to get ALL the live streams for a specific game so I’m making a chain of requests and telling to stop if there’s less than 100. But with this issue it will just randomly stop, sometimes even on the first page. I don’t get it.

Whats the actual request you are making?

https://api.twitch.tv/helix/streams?game_id=32982&first=100
If I make the above request right now it returns (randomly) either 98 or 99 results. Even though there’s more than 100 people streaming GTA V right now.

Weirdly If I do the exact same but for VALORANT it returns 100 pretty consistently
https://api.twitch.tv/helix/streams?game_id=516575&first=100

Same issue for RDR2. There’s more than 100 streams but If I do this it returns 98/99
https://api.twitch.tv/helix/streams?game_id=493959&first=100

Seeing similar. Not sure if bug or something else.

Pagination with streams has a lot of fun issues.

best bet is to potentially paginate till you get no more cursor.

I tried that. But then it will keep going forever because there’s always a cursor, even on the last page.

My only conclusion is that the first parameter is broken because anything you put, it might return somewhere between 1-4 less than that. I just changed it to &first=80 and it returned 79.

Stopping when the results is less than the first param is an unreliable way to paginate even if this was working perfectly.

The reason is, if the total number of streams is a multiple of your first param the final page would have a results equal to first, and because it still has a cursor (Get Streams endpoint has a cursor on the final page to allow for traversal of results in either direction) if you blindly attempt to use that cursor as the after value it’ll loop you back to the start and you’ll just endless loop.

To properly paginate the Get Streams endpoint you need to not assume that results < first is the end, as there could still be more pages. You also need to retry any bad cursors, such as IA. And you need to detect looping, this can either be done through a check of the cursor length/decoding, or by comparing the results you’re getting to the results you’ve previously collected (if you jump from results with 1 or 0 viewers, to a page of streams with hundreds or thousands, you’re back at page 1)

I am also getting a different number of items on each page when using the /clips endpoint.

These requests return 61, 52, 45 results respectively, in spite of the first=100 parameter.
https://api.twitch.tv/helix/clips?broadcaster_id=423486275&first=100&started_at=2020-02-28T18:24:27Z&ended_at=2020-02-29T14:24:27Z
https://api.twitch.tv/helix/clips?broadcaster_id=423486275&first=100&started_at=2020-02-28T18:24:27Z&ended_at=2020-02-29T14:24:27Z&after=eyJiIjpudWxsLCJhIjp7IkN1cnNvciI6Ik1UQXcifX0
https://api.twitch.tv/helix/clips?broadcaster_id=423486275&first=100&started_at=2020-02-28T18:24:27Z&ended_at=2020-02-29T14:24:27Z&after=eyJiIjpudWxsLCJhIjp7IkN1cnNvciI6Ik1qQXoifX0

Checking the cursor parameter instead of comparing total with first is certainly how it should be done, but the problem is we need to do more requests than expected.

Clips is unrelated to streams

See also

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