Deprecation of Create and Delete Follows API Endpoints

At least it’s better to downright remove this API than do what happened to whispers and add spam filters which block everyone but some users who can actually send whispers without getting cryptic errors or the interface just not working. :frowning:

Whispers broke and you can’t receive PMs from what Twitch considers strangers, only way to fix it is to either give them mod powers in your chat or follow them. Great that the create/delete API for follows doesn’t fucking exist anymore.

I don’t really know what to say. I am shocked about this decision, disappointed, annoyed, mad, and to be honest, not even surprised. Unfortunately, I’ve only seen this announcement just now, as I’m currently affected by the major floods in Germany and still don’t have an internet connection at home with very limited mobile connectivity.

With the decision of entirely removing the follow/unfollow API endpoints on both kraken and helix, you’re killing one of the (last) major features of my application which I’ve been working on and maintaining for eight years, since 2013.

The reason for your decision seems very shortsighted and not properly thought through. Developers of abusive bots will for sure find other ways around that, eg. by simply switching to your GQL API, and all you’re achieving here is hurting legitimate developers who have been using your public APIs for several years.

Let me say it as it is, this is probably your biggest public API related fuckup yet. And I’m saying this with the entire history of mismanagement and negligence of the past years in mind, namely on kraken v3, kraken v5 and helix, especially with how you’ve been treating us 3rd party developers. Last year you’ve finally promised to improve the overall public API situation, especially on helix, as kraken was being cut down again and again for no apparent reason, but even this hasn’t really been accomplished yet, and now you’re basically blowing a big hole into the feature set of both of them, without any plans of not hurting your legitimate 3rd party developers. Great job!

What I find unbelievable is that instead of providing a solution for those legitimate devs, you’re waiting for our reactions to your decisions first and then expect us to make suggestions on your feedback tracker, which will then probably be ignored, just as usual, same with dozens of API bug reports on GH, etc. Not to mention that any “solution” which would require a workaround, like for example making the user visit your website in their web browser just to follow/unfollow users/channels (and games) would be an incredibly bad user experience for basically every 3rd party application, and is thus not a “solution”.

What you should’ve done instead of simply removing the follow/unfollow endpoints on kraken and helix in such a weird rush, is either whitelisting trusted devs or rate-limiting follow/unfollow endpoints with entire client-IDs, so that registered applications can’t abuse the endpoints. Since you should have enough data about which client-IDs are abusive and which are not, whitelisting/approving legitimate developers sounds like a no-brainer. Maybe even implement different levels/tiers of trust for devs which will unlock certain features. This would also help with bots which are distributed over multiple client-IDs.

Properly contacting us developers with simple emails instead of writing this “rather hidden” thread on your dev-forums which most of us will only ever visit once or a couple of times a year should’ve also been a no-brainer, but this shows how you’ve been treating us 3rd party devs. Please also don’t say that you’re not neglecting the state of your public APIs, because that’s exactly what you’ve been doing, especially since the days of the GQL API on your website, as already pointed out in this thread.

Removing such important features and how this is being handled is the equivalent of showing us the middle-finger. And this will of course also hurt smaller channels on your platform, as users of 3rd party application won’t be able to follow with their accounts.


For the record, from the Twitch Blog when it was posted with the one month warning

And this Forum Post/Blog Post were cross posted to the announcement section of the Developer Discord. And cross posted to the libraries Discord

Both of which you can find linked on Support | Twitch Developers

So it wasn’t just posted to the Dev Forums. You can also enable notifications for the announcement category of the forums to recieve announcements via Email.

Can you share your data used to make this claim of how big the impact is, particularly on smaller channels? I’ve not seen any evidence of this beyond those who are developers of these apps making angry accusations without anything to back up the usage of such endpoints, as even within the developer community there is little support on UserVoice for this.

I agree with this 100%. Users are accustomed to seeing a :heart: and being able to favourite/unfavourite , follow/unfollow, bookmark/unbookmark profiles and listings from AirBnB and similar apps. Having to open a new tab to leave the platform to accomplish the same thing not only breaks the user experience but as a developer makes it not worth trying to include the feature to begin with, no matter how much it may benefit smaller streamers in particular.

As a case in point, I had plans on developing such a feature that would allow users to easily follow streamers of interest, that I am sure would have benefited hundreds and hopefully thousands of smaller streamers, but as I saw here that the endpoint was being deprecated I sadly moved that user story to the icebox. :disappointed:

If whitelisting apps for enhanced API endpoints like follow/unfollow is off the table, I think rate-limiting by app (App Token) or by user (OAuth), or both, is a very sensible suggestion that ought not to lend itself to abuse in the same widespread way that led to the concerns with these two API endpoints to begin with.


I will also echo the sentiment that I’m very frustrated by the lack of appropriate communication here. Our product did use this API but we have the luxury of being able to migrate to the GET endpoint.

A forum and blog post is not an appropriate communication mechanism for breaking changes like this. Our product is huge and interfaces with a dozen API providers and it’s impractical for us to be checking the every provider’s blog/Twitter/forums. The bare minimum here should have been proactively sending an email or two.

This last point is less egregious and more open for debate, but I also believe in inappropriate status code was chosen when deprecating the endpoint. HTTP 410 would’ve been my preferred choice given that returning 404 was a valid and acceptable response when the endpoint was working. I acknowledge that we should have been matching on specific messages rather than purely the status code, but handling this better would’ve reduced our troubleshooting time greatly.


I also just discovered there’s no way to follow/unfollow in the new API and that has thwarted a planned a legit usage for it. My game SpyParty has a notifier that uses the twitch API and tweets and posts in our discord when people stream the game. I do different cool stuff depending on how many times they’ve streamed it (for example expanding their preview card on discord after they’ve streamed 5 times), and I was planning on having the official channel follow folks who regularly stream the game so its lists of followers basically matched the current streaming community for the game. It appears I can’t do that now.

I agree with the posters above that any spammers are just going to use selenium or whatever and this probably barely slowed them down and only impacts legit developers, and having a whitelist application for devs and rate limits would have been a much better solution for the twitch developer ecosystem.


PS. I’m also not a huge fan of the “vote it up” way of doing feature requests and bug fixes by sites these days, you end up with a bunch of surface level sexy stuff that doesn’t actually make the core system any better or more flexible, in my experience.

1 Like

Given this doesn’t show on the website for other people, and only shows to the person logged into the official channel’s account.

You just need a page on your website somewhere that will list the channels that meet this crtieria that are live. Since using the API you can look up 100 channels stream status in one go. This also means you don’t hit the 2000 “people I can follow” limit.

Hi, I already have that page on the website and have for years. Players think it’s really cool when the official account follows them. For a small to mid-sized indie game, there are nowhere near 2000 people regularly streaming the game so that’s not a remote worry and would be very much in the “good problem to have” category, but hey, that limit is just another argument for having an API that can follow and unfollow because I could have the bot curate the list to whatever limit based on whatever stats I wanted. Thanks for your thoughts on this matter.


Hasn’t this been revoked? Shouldn’t this mean follow bots are no longer a thing?

My channel keeps getting followed by some Hoss bot in all different names and spellings. How are they doing that if bot follows are no longer a thing?


They use the first party APi that they are violating the Developer and regular TOS in using. Or employ humans to manually hit the follow button.

What an unexpected surprise!


And naturally Twitch is working on combatting this, which I thought went without saying.

I reckon most if not all follow botting was done via GQL, so Twitch is fighing the issue via multiple vectors.

Some follow bots that were being tracked operated within the 3rd party rate limits, where as if they were using GQL they could far exceed that, so that would indicate that at least some of the follow bots were using the 3rd party endpoints which this change has successfully stopped. As for the stuff that hasn’t been stopped, like Barry said that’s also being worked on internally at Twitch.

What in the fuck did you expect! Literally nothing changed about follow bots. Just the sincere third party devs Twitch apparently cares so much about got fucked. And now we have to find ways to somehow do in-app follows (using your 50MB of JS website for a fucking follow button is a waste of everyone’s time and resources) and yet not break TOS and DA at the same time. Shit like this makes me consider leaving developing for this platform altogether (I assume other devs have the same feelings as me). I’ve personally seen ‘illegal’ GQL stuff (not my own obviously) break less than programs using your official APIs for fucks sake!

Something is obviously wrong here.

Was it worth pissing off a chunk of your dev community for stopping a small part (as per what Barry said) of the follow botting procedure? I do not think so. Just look at this damn thread!

How about rate-limitting following to something a normal user won’t exceed? You already do this kind of a thing for clips for third parties apps.

Please keep it civil on the forums. There is no need for needless swearing.

Look at this thread? you mean this tiny fraction of the Twitch Developer community (the vast majority of devs either don’t use these endpoints, or have successfully moved on already)? And you value the handful of apps used by a handful of users over the thousands of users impacted by followbotitng and hate raids (some to the extent of doxxing and death threats)?

leaving third party devs no choice is hardly something i call “successfully moving on”


This thread is now locked from further discussion.

Since it’s just going round in circles and people are not being respectiful to each other.

For further feedback on this change please post to uservoice citing your usecase and reasoning.

Here is one of a few related uservoices.

And the “main” developer uservoice can be found at

And to cite the original post for those that arrive at the end instead of the start:

And Jon later in this thread regarding feedback:

1 Like