As We all know there is only 7 months left until the v5 will be deprecated and Helix will be the only API for us to use. I have been watching Helix development since the introduction and I feel like a lot of the features of the old APIs are not implemented in Helix.
Now, obviously Helix is not done yet so more stuff is being added but what I see from already implemented Helix endpoints that We are actually losing features from v5 and even v3.
A good example would be the games and top games endpoints.
On Helix If I wanted to do this, well I wouldn’t be able to do this on Helix. The top games endpoint is already implemented and it has been for a while without any changes so it seems to be finished.
https://api.twitch.tv/helix/games/top endpoint gives back nothing but the game id and boxart, thats it. Even individual games endpoint returns the same thing. No way to get any statistical information about games or viewers any way possible.
Now, I feel like this is intentional and would like to get some clarifications from the devs if it is so. I also would like to ask other 3rd party devs, how they feel about Helix and If it is going to be ready to use ? or even if it is ready, Will it be enough for us or it will be the gutted version of the old APIs with most of the current features have been removed.
Thanks for reading and please correct me if I have missed anything.
I’m also really concerned that 3rd party devs are running out of time.
Currently, I’m rewriting a Twitch based project but can’t release it since required endpoints are missing in the Helix API. At this time I need to use Helix AND v5 Endpoints which makes developing a pain in the a**.
Currently, it seems like Twitch only focuses on Extension development rather than API…
I’d claim that most of 3rd party Twitch tools have been developed as a hobby-project. These developers can’t invest much time in maintaining their tools - not a smart move to ditch this huge part of the dev community.
Main thing I’m missing is a channel subscribers endpoint, I’m hoping the reason for it taking so long is because it’s getting some much needed love compared to what v5 returns.
A Helix chatters endpoint with id’s would be nice too
Honestly though, for my needs I’m happy with the progress Helix has had and how we’ve been kept in the loop more than some other places would have. Yes it’s a shame v5 is deprecated before Helix is finished, but Twitch is a continually evolving platform so I design my analytics app with flexibility in mind to adjust as and when needed as new endpoints are released.
I didn’t see the Community or Teams endpoints in the documentation - or on the Trello Roadmap. Those are the last endpoints I need to port CouchBot over to be completely on the Helix API. For now, I’ve just been using both APIs.
Will check back here and see if Amorelandra is able to find anything out for us.
I am curious about this as well…I just started working with the API recently and all I really need to finish my current project is a simple subscriber count, similar to the ‘total’ from follows in Helix. I don’t really want to take the time to dealing with v5 when Helix seems simpler to work with and v5 is on the way out. This seems like such a ‘core’ element of the API that I am really surprised that it is not available yet.
For a project I’m working on, I’m going to be (temporarily) relying on https://dev.twitch.tv/docs/v5/reference/bits/#get-cheermotes to tell me which tokens are cheermotes because the PubSub Bits event doesn’t tell me. But, with v5 being deprecated and that API call being removed, I don’t see a replacement in Helix.
I’ll toss my name on the pile. I’ve just recently started working with the Twitch API and frankly I find it very concerning that there is such a strict date for removal of the v3/v5 endpoints when Helix seems to have less than half the functionality they provided.
I get the sense that this is a deliberate move on Twitch’s behalf to reduce the amount of access developers have to data. As a developer working on a new project, it’s very challenging to determine the best approach knowing that theses APIs will be removed so quickly without a replacement already in place. If I build functionality around the old ones right now, I have no real confidence that my feature will even be possible come Jan 1 next year.
Not to mention the impacts on timelines and investment… For those of us working for companies, not just as a hobby, this is essentially costing the business double the man hours for a single feature, since it will need to be built and rebuilt within a 7 month period. On top of that, for all we know, many of these replacements may not launch for another several months, putting a significant amount of pressure on developers to rewrite functionality in an extremely short period of time; and that last point is assuming there’s even an intent to replicate all existing functionality, which I believe is not the case. Not good!!
Thanks for bringing this up, I share the same concerns.
I have been working on a project that relies on the viewer and channel count provided in the games/top and streams/summary endpoints of Kraken. As Helix does not have this information yet and Kraken is scheduled for deprecation I’m unsure how to continue.
Include the viewer and channel count in the helix/games/top endpoint.
Add the summary endpoint to helix/streams/summary just like with Kraken.
Looking forward to get some clarification on this from Twitch devs.
I brought this up a month or so ago and never heard anything back. I too am fairly concerned with Twitch providing a fully working API even 6 months prior to the removal of the older APIs. I agree with @Syzuna, 6 months is a good transition time.
I am working with another company right now that is implementing an open API and have been working with them for almost a year as fixes and updates are made. They have a lot more endpoints than Twitch provides and handles a lot more data but my point is, testing out a change like this takes time and I would love to have a “finished product” to really test against and more than a month or two to test it.
One of my big concerns with Helix is going to be the maintainability of the applications on our end. With Kraken, there have been countless times where an endpoint would roll out, but the response structure could change without warning. It’s almost as if updates were pushed out without proper QA/QC, hoping that whatever was pushed worked and met everyone’s needs. And to make matters worse, the changes would go undocumented for quite some time, often until they were pointed out by us. I know one of the goals with Helix was to avoid situations like these, but there have been a couple cases where this still occurred.
In my specific use case, I’m building a general use library for all of Helix, and more. I’m not looking for a specific set of information within the responses, but the entire responses themselves. When data structures can suddenly change without warning, this makes maintaining my library an absolute nightmare. Usually I only find out during my own testing, or through other people’s bug reports. This can, and has, resulted in situations where I thought I finished implementing an endpoint, to only realize that I’ve been “ignoring” data for quite some time.
Twitch has been getting better at notifying what changes, and where, but reporting these changes is usually very slow. Take, for example, the recent msg-id=giftsub tag with IRC (I know it’s not the API but the concept is the same). This tag was rolled out publicly weeks before there was any mention of it in the documentation.
I would love if there was automated way to check what the response structure should be, but also the query parameters used to make the requests. Currently, the only way to test the response right now is to manually hammer each endpoint and compare the content of the response vs. what was previously returned. This could be automated to an extent on our side, but it shouldn’t be that involved to maintain our applications so that they stay up to date at all times.
A solution along the lines of what was discussed in this thread would be an amazing thing to have access to, automated documentation from the source level. This was we know exactly what we’re getting into. An Open API specification for Helix.
An Open API specification for Helix would be amazing.
Still no official response from Twitch? That doesn’t bode well… Helix has only a small fraction of the functionality that v5 does, and it doesn’t seem to be progressing (at least, it hasn’t in the two months I’ve been watching it).
I personally need a way to determine the game currently set for a channel even if it isn’t live, for shoutouts. That is the one thing that I still use the v5 API to get.
Being able to determine and update the game and stream title through the API would also be nice. I don’t make use of that in my own code, but one of the programs I use (Chatty) does, and that’s a handy feature to have in the middle of a stream.