Getting the same thing, so looks like something on Twitches end
1 Like
Hi, I have the same problem. Do you find a solution?
1 Like
Hey, everyone!
I looked into this and found out it is a known issue. This should be back up and running after this week. We aren’t deploying code changes during E3.
3 Likes
And blessings upon you and your kin for that decision. It makes my life a lot better not having to juggle updating stuff for twitch and covering e3 stuff.
2 Likes
FYI, identified should be back and working at the /kraken/ endpoint.
2 Likes
Is there any update on this in regards to calling with a client_id within a URL call to the ~/streams endpoint? It still seems to be throwing an empty value for streams that are currently live.
1 Like
I’m wondering this too.
Is including &client_id=xxxx in the URL sufficient to make sure our apps will work? (Once the /streams endpoint is fixed.)
EDIT: Ok, found the FAQ, looks like it’s supposed to work. But, I’m not sure how to test it. If I call https://api.twitch.tv/kraken/channels/superfight?client_id=xxxx it works regardless of whether I put my actual key or a random number in the URL.
1 Like
“All endpoints that start with api.twitch.tv/kraken will require the Client-ID headers. No exceptions.”
Does it have to be in the header, or does adding “&client_id=xxxx” in the call url work? And if so, how would I test it given that there seems to be no difference when I put a random number in instead of my key (wrong client_id does not give me a failure)?
1 Like
@Praxis: The third and fourth questions in the FAQ answer your questions. The correct way to test is included there along with pictures. Let me know if you have any more questions! 
1 Like
Do you by chance have the ability to find out on the status of the /streams endpoint being broken if supplied with a URL-based client_id?
FE:
https://api.twitch.tv/kraken/streams?channel=whateverchannel&client_id=whatevercodehere
as it still stands, that returns an empty set as if the streamer was offline, despite testing on people I was watching already for a bit. Last thing mentioned about it was ~18 days ago
1 Like
@jaxxx_ol: As Fugi pointed out above, we’re aware of the issue and know how to address it. We’ll update you when the fix is in place!
2 Likes
Hello ,
I’m currently developping a twitch service, and need to track when my users go live on twitch. I understand that the client_id filter on the /streams endpoint was the correct way to do that, but this filter has been deactivated one month ago to avoid the bug occuring with the client_id parameter necessity on all requests.
Do you have any ETA on the reactivation of this filter ?
Is the only other way to get the information I need to issue a request per user ? Like, every minute or so, i check /kraken/:user/streams ???
Thank you for your answers !
@daviddumon: Most folks poll the /streams/:channel endpoint to find online status. You can do that every minute or whatever works for you. Our guideline is 1 req/second. I’ve actually never heard of using the client_id filter for finding online status, but I’m pretty new around here.
We’re still working on the client_id filter and should have it ready to go by the Client-ID requirement date of Aug 8th.
Is there a precise time today when the Client-ID requirement will be enabled?
1 Like
This still going to happen today?
I noticed it isn’t pinned anymore
Hey, everyone!
Quick update on the go-live for Client-ID.
When we scheduled this, TI6 hadn’t been scheduled yet. We came to that revelation when we had an internal meeting about going live with the change. In light of that, we are pushing this out until the 22nd. We wanted to keep today’s date as the official date to drive compliance. It worked! We’ve gone up by 20% in identified requests in the last week but still have a bit to go. We’re reaching out directly to many sites to get them to update but will definitely go live on the 22nd.
For those that have already implemented it, thank you! You’re ahead of the game. Sorry for the short notice!
-Dallas
3 Likes
Just out of curiosity, what happened with this? I just tried today and I still can make unauthorized requests.
We’re turning it on today (maybe tomorrow)! Currently discussing it.
I saw a brief period today where the API returned HTTP/400 Bad Request errors. Is 400 the status code that will be used for requests lacking a client id?
@R1CH Yep! 400 is the status code. That was when we tested it today (and subsequently rolled back). We’ve pushed it until tomorrow. Sorry, everybody!