Today, we announced the availability of API v5 along with a major change in how the API operates. We also announced the upcoming removal of v1/v2 and deprecation of v3 in February. Please make sure you read the entirety of the blog post.
If you have any questions, please comment here.
FAQ
How do I get a user ID from a login name in v5?
We heard you loud and clear. The new API lives here:
Will chatters be updated to use ID and officially supported?
No plans to update chatters to reference by ID at this time. Nothing to announce about official support of the endpoint either.
Does this mean duplicate usernames?
Nope. Usernames will remain unique!
Should I treat IDs as integers or strings?
Strings!
Heya,
A thing I have been struggling with for a long time now is how to upgrade our databases to use IDs. I have a database with 50 million user entries, migrating that to use IDs could be done by making one HTTP /users request per user, but I feel like that is a very bad idea.
Is there any suggested method of going about this?
The example in the post to get the ID of a user in the post relies on v3. Will it still be possible to let a end-user give a username and figure out the possible ID(s) for that username with v5? Or will users have to be trained to extract the user ID from some place like the URL as is the case on youtube (which is a simplification, you can guess a user based on a given name, but there’s so many varieties on how a name in the URL can lead to a user on youtube)?
@CBenni I would say you could do it incrementally as users use the system. Any time they login to your system, call the /users/ endpoint to grab the ID and update your database. Or queue it up for non-production times.
@Larklen That’s correct. Let me know if you see something different!
@freaktechnik You could use /search/channels to get the user ID. With v3 being around for a year, we are hoping that’s enough time for you to get user IDs all set.
@DallasNChains Regarding the removal of _links and the mention of offsets. Will the cursor mechanism be the one of choice to perform pagination in the future? For example, I noticed that for /follows the offset was deprecated in, only what I can assume, was in favor of using cursor?
Right, thats what I feared. I will have to assert if this is feasible from a database perspective. Problem is that if a user no longer shows up or receives a name change before doing so, his/her data will remain in a zombiefied state, breaking the usefulness of the app.
On a side note, will we get a supported, v5-style /chatters API? Loyalty bots desperately need this.
So you are suggesting /search/channels would be a reliable endpoint to use for example if someone enters a Twitch streamer’s username to find the streamer they mean? Is there a way to limit the search on the username? Or is that already what it does?
Again, I am not concerned about the migration, but how users can input twitch users post-v3.
@CBenni I wouldn’t think a name change would be an issue as thats only a localization of the display_name, you could still use the endpoint using their username - though since you raised the concern, I imagine you are only storing the display_name?
As for users not showing up, I assume you mean for suspended users - that may be an issue but if so, I don’t think it would differ from any issue that is present today.
@Larklen I meant an actual name change, like they have been given out in solitary cases in the past. The move towards IDs hints to such a service being released soon™
I do not handle display_names for identifying users at all.
Are you planning to update the twitch-js-sdk library in consequence?
As far as I can tell it uses JSONP and doesn’t set any specific ‘Accept’ header at the moment. I’m assuming this means it isn’t V3- nor V5-ready. Is that the case?
Also note that the same project also lacks out-of-the-box support for the mandatory ‘Client-ID’ header; I’ve personally used the simple diff provided in PR #21 successfully.
Does IRC get affected at all? Will there be ID’s instead of usernames when messages are sent?
Also curious about the Chatters endpoint. Do we use names or ID’s.
Hi, thanks for the update. Will /streams/:channel_url be affected by this change? It’s been said above that streamers can be found through /search/channels but that seems less reliable if I have the channel URL beforehand.
Hello,
I’m wondering how this is going to work to pull up information about a streamer when the user doesn’t want to sign in or is looking up information for another streamer. Do we always have to first perform a search to get the user id and then perform the actual action? I’m aware of the /user endpoint, but you say that only will work for v3.
as i saw now on my tests there is no way to get the user id on the v5 api?
thats pretty bad, i have now absolute no way on the v5 api to get the user ids
i simply let the users put their username in a input field and check with a cronjob if the stream is online or not and if so i display it on the website, so no oauth required, when the v3 goes down 2018 i have no way to get that informations (you cant check with https://api.twitch.tv/kraken/streams?channel=a,b,c… you need the userids)
how i supposed to do this? (as a normal user u dont see anywhere your userid so im unable to say put your userids instead of the usernames in)
edit: ok seems like i found a solution (isnt great but it works)
im just using the search/channels endpoint of the v5 api and check if the channel i search is in the results and grab the id from it and cache it then $ret = getData("https://api.twitch.tv/kraken/search/channels/?query=".$stream);
I also think it’s a bad move from usernames to userids without any way to translate in v5!
Especially as the root endpoint does return the username and not the ID!
The root endpoint should really return the userid…
What is the correct way to read out informations about the users channel that is authenticated with the token?
Until now I made a request to root and received the username I then used for /channels/USERNAME calls and didn’t need any additional scope. Does that mean I now need the “channel_read” scope even so I don’t need any private data or do I always need to trigger a search?