Safety is central to everything else happening on Twitch and we want to empower developer contributions for safer communities. In the past year, we’ve heard from developers and broadcasters in the community that they could greatly benefit from Twitch API functionality with a focus on safety. For example,
While Twitch continues to add tools to the creator dashboard, we also recognize that third-party developers are capable of delivering tremendous value to Twitch creators regarding safety. By providing API functionality in this space, developers are able to build tools that can be leveraged by a wide range of creators or tailored to the specific needs of a community.
We are releasing nine new API endpoints and seven new authentication scopes that focus on community safety. Through these scopes, both broadcasters and channel moderators can authorize third-party applications to use these endpoints on their behalf.
Please feel free to provide comments and questions in the thread below.
New Twitch API Endpoints
Ban Users – Ban one or more users (up to 100) from a channel. Duration and reason can be provided.
Unban User – Remove a ban or timeout for a specific user.
Get Blocked Terms – Get the broadcaster’s list of non-private, blocked words or phrases.
Add Blocked Term – Add a word or phrase to the broadcaster’s list of blocked terms.
Remove Blocked Term – Delete a word or phrase that’s being blocked in the broadcaster’s chat.
I’ve mentioned this a while ago on UserVoice in a different discussion, but it would be really nice if we were able to add mod comments when banning users, either by chat command, or now since there’s an actual API endpoint via an extra field in the request body.
The reason is that while a user should obviously always get some level of detail on their banishment, there is often certain information that ultimately lead to a ban that should either not be known to the user or only gives additional context to the moderators themselves.
Right now the only possible way to do so automatically, especially when banning in bulk, would be to use the GQL endpoint, but that is obviously not a real solution.
Additionally, in my opinion both the Get Blocked Terms and Add Blocked Term endpoints should include a private field if the moderator_id is equal to the broadcaster_id so we’re able see and manage private blocked terms if the broadcaster gave us access to do so.
If you could also see about fixing the bug when pulling over 6000+ banned chat usernames through api that would be great as well. Thanks in advance for these tools.
Much appreciated, thank you. I expected the new scopes to need reauth with all of my streamers, but having them mod-scoped is a very welcome bonus. Kudos!
A little bit of immediate feedback: For bans/unbans, a way to suppress them from showing up in chat for mods/broadcasters would be ideal. For example, since we can now ban up to 100 users at once using the ban API, that has the potential to flood their chat with up to 100 ban messages. A way to limit those to only showing in mod actions would be cool (or even by default).
BIG Thanks to devs for the ban endpoint \o/
Can’t ban lot of users (for exemple after a follow bots attack or bots spamming in chat), because of IRC rate limits. Thanks to this endpoint, we can now bulk ban without trigger the IRC rate limit !
Banning in no way prevents follow bots, they can still follow users when banned. Additionally the vast majority of follow bots are harmless and don’t impact chat and so official guidance as well as best practices are just to ignore them.
Not really possilbe since a ban will also send a CLEARCHAT to remove any messages that are in chat from those users.
And the CLEARCHAT is generally what triggers the notification (ignoring pubsub relayed events and the like)
So the notification is required for other moderators to know
And channel bots/other tools to know
That a moderation action is occuring.
Additionally allows other moderators to be aware if a moderators account or their token is comprimised. You don’t want a moderator to randomly go and start banning everyone and then none of the other moderations observe this due to no chat notifications for the events, for example.
It also means that a ban via the API is functionally identical in all the steps compared to a ban via Chat.
It does impact the common used third party alert overlays (StreamLabs, StreamElements) though when 150 bots follow and unfollow several times in the span of a few seconds. As well as ruining widgets that show latest followers. It just depends on how you look at it really. But… credits to the Twitch team. I haven’t seen many followbot-attacks anymore.
This is why it’s increasingly more common for streamers to not use alerts for followers as they realise it can be a vector for abuse with little way to mitigate, that follower count isn’t a metric of any real importance, and adds nothing to the value of the channel itself.
While there have been attempts to mitigate follow bots, but they all have issues. For example, blocking a user prevents a follow, but that doesn’t help after the fact. Bot lists exist, but new accounts are created far faster than any of these lists update, and they contain false positives. There are also bots that advertise they can stop follow bots, but again these just try to block bots after they mass follow which is too late and there are some bots specifically aimed at this which are known to have false positives which they don’t correct.
Because of this, attempting to prevent followbots takes time, effort, with a high error rate that will negatively impact legitimate users. Or, the streamer could just not use follower alerts and not need to care about the bots at all as like I’ve previously said the vast majority of follow bots do not disrupt a stream in any way other than following, which doesn’t do anything if you don’t have follower alerts.
Finally, streamers trying to remove followers has lead to them seeking out tools to block users which removes the follow, but there is a significant number of streamers who end up removing legitimate followers, or worse removing EVERY follower. So by going against the advice to just ignore the follow bots, many channels have negatively impacted their channel far more than the bots ever could.
Absolutely agree on the technical part of your reply. I do believe though that the psychological effect of having alerts and follower names on screen shouldn’t be underrated. It ‘rewards’ the viewer for hitting that follow button and simply creates engagement with the viewer which increases viewer loyalty.
Some platforms have introduced a skip button which will skip all alerts queued (see image below) and most big platforms don’t give notifications for refollowers.
I’ve been seeing some issues with these endpoints with quick bulk edits. In the described cases the requests were basicially sent without delay, but nowhere near enough requests to get close to any rate limits (that I’m aware of, I check the Ratelimit-Remaining reponse header for every request).
When adding terms:
I add a batch of terms rapidly and each request successfully returns a status code 200 with the expected JSON containing the data of the created term.
Both the “Get Blocked Terms” API and the website don’t show some of the added terms. For example when adding 10 terms (abc0 to abc9) only 7 terms show up.
Trying to add one of the missing terms again will again appear to be successful, but after reloading the list it still won’t be there.
After a while (I have seen between 10 minutes and over an hour) the missing terms show up in the list, although I’m not sure if it is always all of them.
When deleting terms:
Get the list of terms and delete several of them rapidly, each request returning status code 204 as expected.
When reloading the list, most items have been deleted, but some are still there.
Deleting them again (with the same id) appears to remove them.
Adding a 500ms delay between requests seems to avoid the issue so far. Lower delays such as 100ms seemed to work as well, but I haven’t tested it as much.
I did another test yesterday around when I made my previous post and the missing terms hadn’t yet appeared until now. Trying to add the missing terms seemed to add them, but they didn’t actually appear in the list (as previously described).
Then I tried to delete the id of one of the missing terms after trying to add it again (as previously described, it does return the JSON, where I got the id from) to see if I could maybe then add it successfully again and not only did that apparently work, in addition several terms I must have added yesterday (but that were missing from the list) suddenly appeared. So deleting one of the missing terms must have flushed some sort of buffer or something that affected more than just the deleted one.
@tduva Thanks for the feedback and detailed descriptions. Apologies for the delay…I had a draft reply sitting here for days. I’m passing this along to the API team investigate the behaviors you described.
