JOIN/PART/MODE events are unreliable because (1) once a stream chat reaches 1k chatters the batched events stop being sent and (2) the batched events are still funky as some users that have not left the chat will, at times, be reported as having done so.
As far as the endpoint you specified is concerned, it is undocumented and suffers from the same issues as the batched IRC events. Its simply a web endpoint to an (internal) list used when compiling the batched JOIN/PART/MODE events; simply put if an IRC client were to maintain a list of who is in a stream’s chat via IRC standardized events it would end up with an identical list that the specified endpoint refers to.
With that said, I use a mixture of methods when tracking a user’s time spent in a specific streams chat; though once a stream hits 1k chatters, the methods break done to non-usable.
(1) Monitor the JOIN/PART events; this gives a baseline for who is in the chat, but is not entirely accurate.
(2) Any user that speaks is assumed to be in the chat for the next two cycles of batch events.
(3) Any user that is assumed to be in the chat but, after two batch cycles*, has not resulted in a join event is assumed to have left the chat.
*: This is two sets of batchevents with the user being considered idle(no events received for the user) in the stream’s chat