Is there a new target date for this going live? It would be nice to know when I should start checking to see if I missed anything.
I’m working on nailing down a date for this now. We’ve turned it on a couple of times to test but broke various things in the process. 
This is now live. We’re monitoring to make sure nothing on the site is broken. I’ll keep you posted if we revert the change!
Thank you!
Can we get an update to the Github page https://github.com/justintv/Twitch-API/tree/master/v3_resources of the Client-ID requirements? Much appreciated.
Edit: I don’t want to post another reply so here it goes.
https://api.twitch.tv/kraken/streams/food seems to work without Client-ID, so does
https://api.twitch.tv/kraken/streams/monstercat and https://api.twitch.tv/kraken/channels/food while https://api.twitch.tv/kraken/channels/monstercat has a client-id requirement?
Has this not propagated yet or do they get special privileges?
Looking into this. Thanks for that information!
Hey guys, I’m a total noobs regarding this (sorry for that), but I have a question. I brought a Wordpress Theme (https://marcelpetzold.com) and I keep getting the 400 Error. The Theme tries to get the Stream Name, Game and Profile pic. Is there anything i can add to the php files in Wordpress to get it working again? It worked perfectly a few hours ago 
Sorry to bother you with my inexperience.
Greetings,
Marcel
Hey, @MarcelPetzold!
You’ll need to add a Client-ID to the request. Get a Client-ID by registering a Developer Application here: https://www.twitch.tv/settings/connections. On your index page, I see that there are multiple $.ajax calls to the API starting on line 210. You need to change them all to add the header. You can see the jQuery example in the blog post.
1 Like
This was extremely helpful. Thanks!
Thanks a lot for the reply! Sorry to bother you guys again. I have like no coding skills at all. I’ve got my Client-ID and changed it in the example. I just dont know on what exact point I need to paste the code. 
@MarcelPetzold If you’ve purchased the theme I’m sure the one you purchased it from should be able to assist you with this. They would need to update their theme nonetheless.
Would I be dumb for just leaving the client-ID in my source code for everyone to see? Or should I require everyone to get their own client ID and make my program use that specific ID for requests? What could happen if someones uses my client-ID incorrectly?
Client-Id is public, client secret is private. You don’t need to protect the client id.
If you are passing in an OAuth token, we will figure out the Client-ID for you.
this
https://api.twitch.tv/kraken/streams/kutu182?oauth_token=blablabla
return
{"error":"Bad Request","message":"No client id specified","status":400}
Did you check if your token is valid? I use the same method and mine works fine… I set it up today.
Can confirm, but only for /streams and /streams/:channel.
yes, other requests with token work, except this one
Isn’t the Client-ID meaningless if its public? People could hijack somebody elses Client-ID and get it banned, no?
@hlcws Not meaningless. At its core, it is a tracking mechanism. It allows us to identify and find any offending applications, contact them, see if there is abuse (or an accidentally shipped bug, which happened about a month ago), and help the application get into a good state. It isn’t meant to be something we track and immediately swing the banhammer the minute you start hammering the APIs. It is a point of data used to inform our research and outreach.
Isn’t the Client-ID meaningless if its public? People could hijack somebody elses Client-ID and get it banned, no?
I guess @hlcws meant that anybody could use any valid clientID in his hands to make api calls with this clientID in header, lets say an Android app runs without any authentication some api calls clientsided with an 3rd party clientID in header.
this 3rd party clientID can not be protected from this kind of abuse, and i guerss thats what @hlcws is pointing at.
That’s how I read it, too and how I framed my response. Specifically the part about seeing if there is abuse. If we see an instance of abuse, we can work with the developer to identify and move forward. The alternative here is that we require an OAuth token for every API call. If it becomes a problem, we will work toward addressing it.
1 Like