@jaxel As stated in the blog post, docs are coming in mid-Dec. All endpoints that reference a username will now use an ID. That includes the channels endpoints.
Okay, what about the fact that subscription lists are stored as usernames, not user ids?
@Jaxel You mean the response from the subscriptions endpoint? It should contain the user object with the ID of the subscriber inside of it.
Is v5 not default yet? Tried the following in a browser and all return âChannel â40000775â does not existâ.
https://api.twitch.tv/kraken/streams/40000775?client_id=N/A
https://api.twitch.tv/kraken/users/40000775?client_id=N/A
https://api.twitch.tv/kraken/channels/40000775?client_id=N/A
Doesnât seem to be default yet, but you can use it by sending the Accept: application/vnd.twitchtv.v5+json header. Iâd avoid using it in production until itâs documented, but itâs good to prepare early.
Agreed, seems like a volatile situation right now.
I set my header to v5 and tried:
https://api.twitch.tv/kraken/streams/seeingblue
https://api.twitch.tv/kraken/users/seeingblue
https://api.twitch.tv/kraken/channels/seeingblue
All returned user not found. Thatâs concerning, because I donât plan on using v3 nowâŚ
I guess it wonât be SO bad since the user ID is transmitted in the IRC message, but for loyalty bots we need their ID when they join the channel.
@SeeingBlue Nothing volatile about the situation. 
v5 wonât be default until we remove v3 in 2018. You should be actively moving your code to v5 if possible. Why is the response concerning? Thatâs the correct response as all endpoints refer by ID instead of username. Thatâs the majority of the change in v5. Try this:
https://api.twitch.tv/kraken/users/40000775/?client_id=XXXXX&api_version=5By volatile I simply meant that it doesnât look like everything is nailed down just yet, as this threadâs conversation progresses and changes are suggested.
Itâs concerning because as a loyalty bot developer, when a user joins a channel, I only have their name. I canât poll the API with that to get their ID so I can store both in the database. I canât tie them to an ID until they actually speak in channel, which might be neverâŚ
Using v3 is good and all until it doesnât exist, then how do I check the ID of new users? IMO if the usernames are going to remain unique then allow us to use both.
2 Likes
@SeeingBlue While not an ideal solution and I hope there is something better available, in V5 you can still search for the user to get their user_id.
https://api.twitch.tv/kraken/search/channels?query=USERNAME&client_id=CLIENTID&api_version=5
And then poll through any results for a âname:â that matches, then that token will be the one and can pull the _id.
But as I said, thatâs a lot of polling/processing just to get a piece of info so hopefully there will be a better solution as more is revealed about V5 and such. Not ideal but a temp solution if you move to V5.
1 Like
An endpoint that takes a username and gives its ID (user object) in return is definitely needed.
5 Likes
I donât know if weâre entitled to the answer to this question, but would it be possible to know the WHY?
I mean if usernames will continue to be unique, why change to useridâs? Because frankly I only see disadvantages.
1 Like
Name changes - a userâs name can be changed, meaning if you use a username to identify the user, then name changes will break your application.
The simpler solution to this problem would be allowing you to change the display name to something different than your username without changing your username, while also making display names unique, the system is already in place and usernames are already used in most bots over display names. In my opinion theyâve gone out of their way to unnecessarily complicate things.
@DorCoMaNdO but with that suggestion, if you changed your display name it still wouldnât change your channel name as that is based on your username, not display name.
Personally, as long as there is a better way to translate Usernames into IDâs than whatâs currently there, Iâll be fine. Itâll mean more API calls, but Iâm sure the devs would have known that this would be the result for a lot of 3rd party developers and would result in more API traffic.
I donât really see channel names not matching display names as a problem, it works fine in YouTube.
@DallasNChains i hope there will be a better way to get the userids for the usernames (maybe a way to search multiple names at ones)
the search works but is inefficient (in the case the right result is not in the first result list its really expensive to do an additional search to get more results)
the way over v3 /users/%username% works but will not availabe forever, maybe its possible to add this to v5 too to have the abillity to search for the userids without perform a general search
So in the blog post it said if i wanted to use v5 I would have to pass the header, so does that mean if i dont change anything in my code (right now it simply goes to the URL, w/ my oauth and everything) it will continue to be in the API v3? Like for example I search api.twitch.tv/kraken/channels/Channel Name?oauth=my oauth, and do not send anything else, like if I was putting it into my browser (which is how I preview what the endpoints look like and what i need to retrieve)
Should I be expecting these changes with v5 or will i still be using v3?
Next February, v1 and v2 are being removed and v3 is being deprecated. In 2018, v3 will be removed and v5 will become default.
@moocat @Stricted @Dist Trying to work that out with the team. Will keep you posted!
@josephcricket The why is really just to enable more features in the future as stated in the blog. I canât be more specific. Sorry!
@GaryTheCoolGuyIII Basically, what @alca said. v3 is the default until it is removed. We donât want to break integrations that donât specify a version.
Has anyone suggested sending the ID through IRC when a user joins just like it does when the user sends a message? If this is possible, it would be easier on the API since we wonât be making double the request.