Cancel the new OAuth for Helix requirements
As well discussed and pointed out in the announcement thread (ref 1). It makes no sense, The matching client id can be grabbed from the oauth url as ClientID's are public right? Atl east your own documentation says so (ref 2) And if not grabbed from the url they are publicly displayed with matching user data and scopes when sending a request to https://id.twitch.tv/oauth2/validate which can be accessed with just a OAuth token. This change is gonna reach nothing but us having to make our code more complicated by having to consistently keep track of client id's that where used for a token or create extra unnecessary traffic on the oauth2 validate endpoint to get the client id used while authenticating back. For more reasons why not to do this please read the posts in the announcement thread (ref 1). Please do us all a favor and just cancel these plans. Thanks
We appreciate all the feedback on this requirement, and understand that it can present additional development effort. While we must continue to adhere to this requirement, we will be providing samples and some simple tooling soon to help reduce the effort.
> This change is gonna reach nothing but us having to make our code more complicated
You mean like how they forced everyone to refactor their code to send extra requests for converting usernames to ids, in order to use any other API? Welcome to Twitch, their whole philosophy is to alienate 3rd part devs and make their lives as hard as possible, in order to make their own lives fractionally simpler.
There's absolutely nothing stopping them from internally resolving usernames to userids the same way the API does, but no, an API accepting both userid or username is too hard for them to implement!
I've worked with many APIs over the past decade, and none has been as awful as Twitch's, changing and deprecating APIs every year for no apparent reason, breaking things, forcing unfinished APIs on devs, etc.