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
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.
Is there a list of the event types to expect in the Hype Train response? I looked at the API documents and all I see is “hypetrain.progression” in the example output. Would be nice to know the others so we can code against it without having to ask our users to push a hype train.
hypetrain.progression is the only event type, there’s nothing else to a hypetrain. Everything from the first progression message that is the start of the hype train until the final contribution is all just progression events.
The documentation for the response was not updated, apologies for the confusion. status and description will be removed from the documentation, and game_name will be added. The example on the right is correct.
I will check on the intended empty value for game (null, empty string, etc)
You are correct about the 200 return code, this will be updated as well. It was a copy/paste error from the modify endpoint.
I will also check on how many broadcaster_ids can be specified and request this be added to the docs; both the maximum and the fact that multiple can be provided.
Good catch, will pass that along to update the delete follow example.
Sorry for the confusion. status and description should not be documented as part of the get or modify channel information endpoints; these were removed during our beta process. User and Channel objects will not be consolidated, the intended differentiation is that a channel object contains the information about a channel page that belongs to a user while a user object contains information about the person.
Noted, the Get Stream Key formatting should be updated soon.
Apologies for the confusion, this is an error. status and description will be removed.
I will double check with the team that only broadcasters are intended to have access through their oauth token or if editors should be allowed.
Thanks for the reports. Passing both to the team.
We’ll be sure to document more types should they become available, but yes, hypetrain.progression is the only one currently.
Is new channel endpoint working correctly? I changed game through new endpoint. If I go to my channel, home shows different game (game before change from new endpoint) than API has. If I click on chat, and it shows channel, it shows correct game. Clips and highlights are from old game as well.
Since Helix can handle User follow/unfollow, can we have the same functionality for Games as well? Imo from the users perspective there is no difference between the two, but it’s a bit wonky that as devs we can do only one of these.
I know it’s not Xmas, but there is one thing i would really like, a random endpoint. We could set the min and the max viewer count (optionally for further filtering we would have language and game) and the end point would return random streams with viewers between min and max, with a limit if necessary.
Personally i want to use this to give access to smaller streamers.
If only the broadcaster token can change channel information, then the broadcaster would have to provide a token to all their editors when they’re using clientside tools. It seems that clientside tools for e.g. mods or editors are more and more shut out of the API by making access broadcaster-only (see also Hype Train Events and Moderator Actions).