Today we are announcing the timeline to decommission the legacy Chatters endpoint that some developers may be using for their Twitch integrations to retrieve a list of users present in a channel’s stream chat. While this endpoint has never been documented or supported, we are communicating this change to limit disruption to third-party applications and the creators that rely on your innovation. As promised in the September announcement for the official Chatters API endpoint, here are the details of the shutdown plan.
What’s changing and who will it impact?
If your application only relies on Get Chatters, then this announcement does not apply. The legacy and unsupported Chatters endpoint that begins with “https://tmi.twitch.tv/” is the resource that will be shut down. During the shutdown windows and after the final date below, developers can expect to receive a 404 error response.
When are we making this change?
Given the number of developers who may be using this legacy endpoint, we wanted to ensure developers have time to update applications to the equivalent Twitch API endpoint and are alerted to the change if previous communications have gone unnoticed. As such, a phased shutdown will be implemented similar to other commonly used third-party services in the past. The shutdown windows to expect are as followed:
Range (Click to view other timezones)
Why are we making these changes?
Programmatically retrieving the list of users in a channel’s stream chat should be information and permission that the creator or their moderators control. The official “Get Chatters” endpoint provides this functionality while also meeting the expectations of these permissions with the introduction of the moderator:read:chatters authentication scope.
What action needs to be taken?
If your application is using the Chatters endpoint that begins with “https://tmi.twitch.tv,” refer to the "Get Chatters "documentation linked above to learn more about the official endpoint and begin any necessary updates. Should you have any questions regarding those updates, please consider joining the TwitchDev Discord server for assistance.
There aren’t plans to change the response for Get Chatters at this time (i.e. the response will continue to be an array of user objects with id, login, and name). To understand which users in the chatters list are moderators or VIPs, requests should be made to Get Moderators and Get VIPs, and then search for matches between the lists.
The website at this time presents a list of people whom have been active in chat recently. The website doesn’t give the full list of viewers out. The first party/unprivileges user offering is very different to what the API provides
In theory, you only need to get Mods/VIPS for a channel once (and/or periodically) then use EventSub to keep up to date with changes. You wouldn’t be geting roles each time you got the list of users in a given chat. So you wouldn’t burn through the rate limit as you suggest.
Join/part messages are not sent on channels over 1,000 viewers, and there are also limitations to how they are sent, for example a join may not be sent until the user sends a message.
As for the chatter list on the Twitch site itself, the list states:
Some active viewers and chatters in the community.
So the public means of getting info on chatters wont be accurate. Where as the Get Chatters endpoint will be a more complete list of chatters and without the issues of using joins/parts.
To some degree it’s similar to how a channels subscribers is partially public in that sub badges when a user send chat messages indicates their subscriber status, but to get a full list of a broadcasters subscribers can only be obtained with their explicit consent to your app.
I ported to this API without issue on the large channels that I operate a currency system on.
1000 per page is not a problem. Speed/efficency is as good as it was using the legacy endpoint. And I have no problems with rate limit.
Would I like bigger pages, for sure.
Do I expect bigger pages, no.
Am I happy with the performance of my loyalty system yes.
Theres more time spent on the databse calls than the fetching and the new system is similar in speed (and marginally quicker) than the old system.
Especially now I get userID’s to start with so I don’t have to name to ID lookup/check first
We discovered and rectified an issue that prevented the first phased shutdown window to operate as expected. As such, the first window has been rescheduled for the same times tomorrow and I will update the announcement above accordingly.