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.
No specific dates for things, just a general roadmap for the 2nd half of this year, which is as expected as Twitch don’t give specific timelines for end, the best you can hope for is the Trello roadmap https://trello.com/b/xdoVhmKj/twitch-developers-roadmap which lets you see which endpoints are Explore, In Progress, or Live. Often there are other things as well that are being worked on but not on the roadmap so sometimes new endpoints will just suddenly go live.