Twitch API update – delaying v5 end-of-life


#1

Last fall, we introduced an all-new API designed to simplify core data models and create a consistent, reliable experience for the Twitch developer community. Alongside this update, we also immediately deprecated and planned to remove v5 by the end of 2018.

Based on your feedback, we are delaying the end-of-life for v5 of the Twitch API. While we recommend using the new Twitch API on new projects, we recognize it does not yet solve for every use case we want to promote.

We’re still working to make the new Twitch API complete and robust. We will provide a migration timeline for v5 functionality and an updated roadmap for the new Twitch API on July 10. We understand that API changes can be very disruptive and we are committed to providing ample time to migrate your apps and integrations.

In the meantime, we welcome your questions and feedback below.


#2

Thank you for doing this!


#3

This is greatly appreciated!


#4

I would rather see Helix to be finished
sigh


#5

that’s the point of this it would seem :stuck_out_tongue: keep this until helix is finished.


#6

Well it is not that great news if you’ve already started a new project with hope that in time it will be ready to lunch Helix will also be stable and feature-rich enough for it to use. Now I need to start working on switching back to v5. Sad.


#8

@Buran same


#9

This announcement doesn’t mean that you should be switching back, only that you should continue to use both.

The new API isn’t being scrapped or cancelled. It’s just taking them longer than expected to roll out remaining features.


#10

I think you said it yourself here, “hope that in time it will be ready.” That is why I hadn’t started any work on Helix. I figured it was a distinct possibility that Twitch, like any software development shop, may have had challenges in delivering on such a huge undertaking and would fall back to the previous working version. I have dealt with this type of decision a lot in my professional job and I appreciate the fact that Twitch understands that the development community would like a decent amount of time to interact with Helix first once it does solve the use cases that they want to promote and, I imagine, is closer to feature parity with v5. This also is better for them, if they extend out the v5 time, it also means more time for people to start to work with Helix and give them a longer UAT (I consider us the users) time period.


#11

There are different implementation specific things in my work which will require some rework of my current code. That is my problems of course. I’m just whining.


#12

Yes, of course I’m speaking myself here. When I saw that v5 will be deprecated EOY and I was going to finish my stuff by they same time I guessed (poorly) that Helix will be on the same level as v3 and v5 by that time. I had some things done for V3 before, but I’ve just decided to skip v5 entirely. This is my mistake and my alone. The progress of Helix was obviously too slow during the year.


#13

I wouldn’t say whining, your complaints are legitimate. Twitch did provide a plan and it was accepted on good faith. I would be upset if I had to write a new API interface when I wasn’t expecting to. I am hopeful Helix doesn’t slip too much and they provide a good timeline come July for us!


#14

Thanks for the update!


#15

Thanks for the update, much appreciated!


#16

Can you confirm if you’re planning to continue support on retrieving all subscriptions of a particular user?


#17

Restrictive rate limits are likely a large reason many aren’t moving from v5/Kraken to Helix. Do you have any plans to raise those limits?


Is Helix gonna be ready?
#18

If you have a legitimate reason for a rate limit increase you can request it. There are a lot of people with sloppy app design that are using an excessive amount of requests, so it makes sense to have a limit rather than a free for all like v5. There are a couple circumstances where a rate limit is a real issue which isn’t easily solved by just upping the rate limit, but for most people with legitimate use cases requesting a limit increase could solve a lot of issues.


#19

Thanks!