Helix API - chat_login scope

[R3V0LUT10N909]

I didn’t find a chat_login scope for Helix API: https://dev.twitch.tv/docs/authentication/#scopes
What should I use?

[george]

The Kraken chat_logon scope is still applicable.

[R3V0LUT10N909]

It works, thanks! But they should update the documentation (https://dev.twitch.tv/docs/authentication/#scopes).

[BarryCarlyon]

How should they update the docs?

There is a list of New/Helix Scopes and kraken scopes…

What would you clarify?

[R3V0LUT10N909]

Maybe I misunderstood the doc.
There are two tables about scopes (https://dev.twitch.tv/docs/authentication/#scopes):

• New Twitch API

• Twitch API v5

I’m using “New Twitch API” and I can’t find a “chat_login” scope in the “New Twitch API” table. So, if “chat_login” scope is valid also for “New Twitch API”, my proposal is to add it to the “New Twitch API” table. Does it make sense?

[Dist]

@R3V0LUT10N909

my proposal is to add it to the “New Twitch API” table.

Chat isn’t part of the new Twitch API though.

[BarryCarlyon]

@R3V0LUT10N909

I’m using “New Twitch API” and I can’t find a “chat_login” scope in the “New Twitch API” table. So, if “chat_login” scope is valid also for “New Twitch API”, my proposal is to add it to the “New Twitch API” table. Does it make sense?

There are no “Helix” end points that you can use chat_login with

[R3V0LUT10N909]

I know, but working with chat requires a token. Instead of using the Kraken authorization URL, I used the new one, thinking it was pointing to different stuff. Then I read in this forum that both links point to Kraken, so we’re saying that it supports all the scopes, both tables? So what’s the point of having two table if it supports both? I’m a newbie here and I know there is a roadmap and everything is a work in progress, but I’m just saying IMHO is not super clear and it could be misleading.

[Dist]

The Helix table are scopes that can be used with Helix endpoints, the Kraken table are scopes for Kraken endpoints.

@R3V0LUT10N909

so we’re saying that it supports all the scopes, both tables?

Yes, because if it didn’t support all scopes you would end up with services that would need their users to log in twice, once to get Kraken scopes, and again to get Helix scopes. By allowing all scopes to be processed together it means just a single login is required.

@R3V0LUT10N909

so what’s the point of having two table if it supports both?

There are scopes that have identical functionality, but for different endpoints, such as user:read:email, and user_read. To have a single table would make it difficult to indicate which scope is for which endpoint, unless you also include a new column to indicate that but then you’re over-complicating it.

I think your confusion comes from you how you switched from the old authentication URL’s to the new one and assumed they were for different things.

[R3V0LUT10N909]

Yes, because if it didn’t support all scopes you would end up with services that would need their users to log in twice, once to get Kraken scopes, and again to get Helix scopes.

IMHO this is the misleading part: you’re saying that it supports both, but there are two table.
Every single API in the documentation has already specified the “Required scope”, so these tables are pretty useless if their only role is to exaplain their link with the different API (Helix/Kraken). I don’t know how people develop stuff, but I usually start from an API, and then I find what’s the scope required and I add it. I don’t think people start from a scope (most of the time the description is not so precise) and then they pick an API.
IMHO these tables should help to clarify what are the scopes supported by the authorization URL (all of them) and I don’t see any value in showing the supported API (and it generates confusion), because that information is already in the documentation. Another solution could be adding this information to the Authentication section.

[Dist]

@R3V0LUT10N909

usually start from an API, and then I find what’s the scope required and I add it.

So by your own explanation, if you go to the docs first, such as chat in your use case, you’ll see it requires chat_login. No mention of other scopes, no mention of separate auth URLs, just 1 require scope, and there’s only 1 auth URL (and that’s independent of Kraken/Helix).

If you don’t find those docs are clear enough then Twitch welcomes all feedback.

[R3V0LUT10N909]

@Dist

So by your own explanation, if you go to the docs first, such as chat in your use case, you’ll see it requires chat_login .

Unfortunately, I didn’t start from the chat, but from the classic “users” API (I guess everybody does the same) and I read the documentation and I realized that “New Twitch API” scopes are in the format “xxx:xxx:xxx” and “Twitch API v5” scopes are in the format “xxx_xxx”. So when I decided to implement the chat feature, of course I read that the only scope was “chat_login”, but I thought something was missing, because in my mind “xxx_xxx” scopes were for “Twitch API v5” API and I was using “New Twitch API”. So I looked at the scope tables and there was no “chat_login” scope for Helix API and I was pretty confused and here I am.
I read so many posts about people don’t uderstanding Kraken is the only “engine” for the authorization and I can tell you those table don’t help to clarify that. This is my feedback and I hope Twitch will improve the authorization documentation adding this precious information that IMHO could help other developers.