A few of my users are getting a 400 response code on https://api.twitch.tv/kraken/users?login=<name>, which is weird because it works for me and (I assume due to lack of reports) at least for most other people, with exactly the same code. I’m sending a client id and it’s using the same code as all the other Twitch API requests. It only seems to be that request and only for some users that doesn’t work. Does anyone have any idea what it could be?
You need to set the API version to v5. The default v3 does not have this “/users?login=” endpoint.
See the documentation for the preferred method(s): https://dev.twitch.tv/docs/v5/guides/using-the-twitch-api/#api-versions-and-mime-types
Accept: application/vnd.twitchtv.v5+json
Non-header methods include:
-
Add
api_version=5to the querystring (using&or?appropriately) -
v5instead ofkrakenin the URL, not necessarily supported by all endpoints I think.
I already send the correct version header on all requests, otherwise it wouldn’t work at all (and return a 404, not a 400). The thing is that it works fine for most people, but not for some, with the same exact code.
My only guess would be either somehow relating to the specific usernames being looked up or a proxy server messing it up between the user and the API.
Which usernames? Just to clarify, it isn’t dependant on the names I try to request, but on which user (clientside) tries to perform the request. So it must be something related to the IP/connection/router/PC of that person that somehow makes the request invalid or that Twitch doesn’t like. And it’s only that endpoint, other endpoints work fine for the same person. If a username of that person is what you want I can try to get it.
Ah! I misunderstood. I thought the API was failing to look up the login name consistently. I thought there might be some wonkiness with Twitch/Curse account merges or something. 
1 Like
So I tried adding the client id and api version into URL parameters, just in case the headers somehow get broken (although I don’t know why it would get broken for just that one endpoint and not the other requests). I also tried to supply an oauth token, just in case that somehow makes it work, but it didn’t either.
The person it doesn’t work for said he tried it on different PCs and over Cable and LTE. There may be others it doesn’t work for, but I only got one other report (and it always worked for myself).
Edit: Also he can open the request URL in a browser (if it includes the client id and version in the URL obviously).
Is there a way to get the reason as to why it considers it an invalid request?
Seems like names starting with _ are the issue. Some users join group chat channels, which the program then tries to request the user id for, but instead of just saying “this user does not exist” the API says the whole request is invalid (even if it contains other, valid names).
I assume usernames starting with _ are not valid names, so I could just exclude those?
For everyone to be clear on the intent of implementation, are you using Twitch as the main authority for authentication in your service, or is it a secondary validation on an otherwise external authentication? If it is the latter, then it might be better to have the account link internally to a user account that the user logs into (Think linking your account on Twitch with Steam, you log into steam independently, then the UID for that connection is stored and used from there).
It is a desktop chat client, not a service. The user can enter a channel to join (or several) and it then has to request the id of that channel in order to perform all kinds of requests. It has nothing to do with logging in or authentication.
A client provides a service, and in this case, it sounds like the user must authenticate upfront to use the application (I’m assuming, you didn’t really answer that, but from the sound of it, authentication comes first, then action). Please note that authentication in this scope is allowing the client to use the data obtained by your account in order to use the API, so the token fetching process. I’m unsure of how to prevent the issue other than a fix on the API side of things assuming i am right on all of that (Please confirm if I am).
You are correct. Usernames cannot start with an underscore. Group chats don’t have a connected channel either (in a technical sense) or really any supported API calls.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.