Today we’re announcing significant updates to the Twitch API. As we move toward one version of the API, a new set of Helix endpoints are available as of today to cover a number of developer needs previously only possible in v5. Please read our blog announcement for more information regarding the endpoints listed below, the Hype Train API, and some results of our recent developer survey.
Feel free to provide any comments and questions you may have below. We hope these endpoints provide functionality you’ve been looking forward to within Helix.
I’m curious to the intended use of the User Follows endpoints, I understand that it would be used with a users token to allow Following and Unfollowing channels from a users perspective.
However calling DELETE on the follower endpoint seems to allow a from_id which is "User ID of the follower", I don’t see why this needs to be specified from the user perspective, as that would be assumed from the provided token.
Does this mean that a Channel (Using the respective channels OAuth Token) has the ability now to delete a user from it’s following list?
Maybe also this endpoint will also lead the an Unfollows webhook, as all webhooks rely on the underlying Helix API?
In Kraken, you can have status and game be returned as null. What happens on Helix in those cases?
It says response code 204 for success, which can’t be right since the endpoint returns data. Sounds like it should be 200.
What happens if the user set their game to something that does not map to a game on twitch, will the game_name be null, empty string or the string they set it to?
Any reason why game_id is a string and not a number? Same for broadcaster_id
How many broadcaster_id parameters can you send? from my short experimentation you can query multiple users at once with ?broadcaster_id=first&broadcaster_id=second&broadcaster_id=third like is usual on other Helix endpoints, but how many is the limit?
and just generally
Link to documentation for “Get Stream Key” leads nowhere, i get sent to the top of the page and “Get Stream Key” is not in the list
Thanks for the quick questions and comments! First, the blog post is now live. Second, I’ll get all doc comments to the team for updates (stream key is known and will be added momentarily). Third, I’ll get product questions to the API to provide the best answers
So I have a question concerning the addition of channels to Helix. Is there a distinct difference between what a “channel” and a “user” is? Because in Kraken, they were essentially the same thing. Going by the new endpoint documentation, a channel seems to be just a stripped down version of a user combined with information that can also be found by requesting the /streams endpoint. This kind of muddies the water a bit, something that I was happy to see gone up until now with Helix.
Furthermore, the fact that you now have two endpoints that can update a “user’s” data is a little convoluted. We can update a user’s description using /users and now the channel information with /channels. This is also ignoring that you update a user’s extensions under child /users endpoints. Are there any plans to consolidate this into one cohesive endpoint/object? Because right now I’m getting flashbacks to the jaded Kraken user/channel experience.
Should be PATCH https://api.twitch.tv/helix/channels work with editor user? I can change game/title with kraken endpoint as caster and editor, I can change it with caster, but editor have 401 error
{
"error": "Unauthorized",
"status": 401,
"message": "incorrect user authorization"
}
I haven’t tested it myself but it requiring specifically the broadcasters token is what I would expect.
A broadcaster has to explicitly grant who can edit their channel, either by going through the OAuth process themselves and granting a token with that scope to a 3rd party, or by selecting a user and making them an editor. If that editor could then go on to go through the OAuth process they could be granting any number of 3rd parties access to edit that broadcasters channel, potentially without their knowledge.
Editors are able to access a channel’s dashboard and help streamers manage their channel by performing the following actions:
Editing stream info
Running commercial break
Editing video info
Uploading videos
Creating events
Starting Reruns and Premieres
Downloading Past Broadcasts
If this is listed, editor should be able to change game/title of stream through API.
Yes I have that user set as editor.
E.g. I have bot account set as editor, I should be able to change title/game with bot and not as broadcaster, you can see history of changes in dashboard and that won’t work if broadcaster account is forced.
Just because functionality on the site is done a certain way doesn’t mean that the same functionality is intended to be exposed by the 3rd party API. Similarly, not all Kraken functionality is going to be provided in Helix.
From a security standpoint it’s beneficial for the broadcaster to be the one in control of which 3rd parties have access to that functionality over their channel. So rather than your bot granting your app (or any app, potentially unknown to the broadcaster) permission to do those things for the broadcasters channel, it’ll be that broadcaster granting your app those permissions.
Sure, I understand, that’s why I asked if it is intended or just oversight so I can properly update code
Edit: Also generally if you give some user some permissions, it is carried across all usage independent on API, UI or whatever so you have consistency unless you can set API access independently. But that’s just my opinion, nothing else.
Just want to know what is correct approach to this change.
Which means it could just be a documentation bug since there are quite a few and some old bugs in the docs reintroduced when the new docs were added. The phrasing about “matching” has only recently been added to the docs (and in some cases removed by accident in this update). So the docs are incorrect in a bunch of places especially round the subject of oAuth/what token is needed.
It is safe to assume that for endpoints using a scope, the broadcaster_id must match the user_id that the token belongs to.
Seems like there’s a bug with the Modify Channel Information endpoint where the response on error has a JSON-stringified object inside its “message” value. Tested by setting the title to a banned word.
