I was using this endpoint to check if a channel exists or not. I was using response.statusCode == 200 to verify that the channel existed, however sometimes I get a response of 400 for a channel that does exist, that has previously returned a 200!
Try refreshing this a bunch of times at different times of the day and you’ll see what i mean.
Don’t think I’ve been getting the error 400, as that pertains to Client ID not being included - have you checked your code to ensure you are always sending a Client ID with your API call?
Sometimes I’ll get a 404 but that’s not very often.
As for checking the stream on whether its live or not, the endpoint is: https://api.twitch.tv/kraken/streams/highstakespoke
The stream object will be null if the stream is offline - it will contain data if it is live.
This might be a dumb question, but are you sending your client ID with the request as is now required?
There’s also /users/:username you can use to check if the account exists. In v3 of the API, this will only differ where the channel has a redirect (such as twitch.tv/help)
3ventic, no, I was simply making an http request to the url I posted in the above reply. I didn’t realize I had to authenticate and use the api . I’ll try that thanks.
To avoid confusion twitch should ALWAYS respond with
{“error”:“Bad Request”,“status”:400,“message”:“No client id specified”}
when hitting it from a browser, instead of sometimes returning the proper information about the channel in json format. I went about a week with it returning it properly (since it randomly returns one or the other), which is what caused the confusion.
It should always return 400 without a client ID, and I can’t repro what you’re seeing; I always get 400 without the client ID. A regional bug perhaps? cc @DallasNChains
It’s random. You’d have to try it at different points in the day. I went a whole week without getting a 400 once, which is how I got into this mess in the first place.
Do you have logs of your request and response times where this is happening, @drivealiveapp? It definitely should always return a 400 without a Client-ID since all of that is centralized across the API. I can’t reproduce this particular behavior right now.