@DallasNChains The blog mentions removal of /kraken/chat/emoticon_index which doesn’t seem to ever have existed so I want to make sure that was not a typo and actually meant /kraken/chat/emoticon_images.
So what is the intended purpose behind this change?
Are we to expect in the future that:
-
Two or more users can have the same username? (with different IDs)
-
Usernames can often change from one to another, so storing a username association to an ID locally would be unwise? (compared to looking it up directly each time)
-
If not, how long should a username association to an ID be stored locally until considered expired?
And more importantly:
What are the intended changes to chat? If we’re associating a user with an ID, it’s going to be a nightmare to have that association with the API but a different one with chat (the username association) It’s going to be total chaos.
What I want to avoid is having to query the API before I join a chat channel. Or having to keep querying about open chat channels cause they might not be associated with that particular user at any point of time.
2 Likes
On the IRC side will the UserID be included in the whois info or somewhere similar or will you need to goto the rest api to do a lookup?
@Kimau UserID has been included in message tags for quite some time already.
1 Like
Also when will the official docs be out for v5 api?
Been years since I wrote my IRC interface, mostly static. You forget what’s there 
Thanks.
Hi,
I’ve been using the SDK you provide: https://github.com/justintv/twitch-js-sdk
(hosted on https://ttv-api.s3.amazonaws.com/twitch.min.js)
Will this break with the new update or will my code continue to work?
Another possibility could be getting rid of usernames entirely (login by email), though I doubt it due to multiple accounts existing on the same email address (I have some myself).
@Hoffs The blog post says “We’re working hard to deliver reference documentation on the affected endpoints by mid-December”
@Maxbit The version hosted behind that link is outdated and shouldn’t be used. I’m sure someone will make a version that works in case it breaks and isn’t fixed in the official repo.
When it comes to name changes, names vs. IDs is the biggest technical change required, but it’s not the only problem with them.
The current flow to access the authorized user’s details that don’t require user_read is to request the kraken root to get the username to use in the rest of the API calls. How would this work in v5? Will the root endpoint start returning user ID of the oauth token owner as well?
Users know and remember their names easily, so an endpoint to lookup ID from username would be desired for v5 for use in apps that allow looking up information concerning other users, such as whether they’re following someone or what their bio says.
Phew. Lots to cover since last night. Haha.
@IllusionaryOne I’m confirming this for you. Right now, you can still send offset/limit but calculated on your side instead of included in _links.
@CBenni Nothing to announce about the supported /chatters API right now.
@freaktechnik It does work that way since you’re searching for a channel. There are issues around fuzzy searches. For example, my Twitch name is just ‘dallas’, and I get everybody with that in their name. I’m going to ask the team about exact match.
@manybots We’re working on plans around the JS SDK now even if just to patch it. The SDK hasn’t been updated in a long, long time, but we want to make it a supported and maintained.
@while-loop v4 was always there. Lurking in the shadows. 
IRC shouldn’t be affected. Chatters is an unsupported APIs and won’t be updated to use IDs.
@azenet All APIs that refer to a channel or user name will use an ID instead. I’ve added an example to the blog post and will add it to the OP here. For your specific endpoint:
v3: https://api.twitch.tv/kraken/streams/moonmoon_ow
v5: https://api.twitch.tv/kraken/streams/121059319
@david Yes. You need the ID. You can use search/channels and get the ID from there.
@Stricted That’s the right way to go about it. search/channels. I’m asking the team about an exact match for username.
@Wolfspirit There is a way to translate from channel name to ID. search/channels is the easiest way in v5. As I’ve said, I’m seeing about exact match on username. I’ll also ask about the root returning the ID instead of the username. Can you help me understand your concern about the /channels/USERNAME endpoint? It has never required a scope, so you can call that to get a user ID now. The root /channels endpoint requires a scope, but that isn’t really necessary.
@celluj34 You mean straight-up Swagger UI output? We’re working on our doc set on the dev website: https://dev.twitch.tv/docs. Stay tuned!
@inb4 I can’t speak to anything around those policies. I’m not on that team. 
@george Hrm. I need to check with the chat team on the index endpoint. emoticon_images is definitely still there.
- Usernames will continue to be unique.
- You could store the association but refresh periodically to ensure you’re showing the right display name.
- No real guidance here. The ID is going to be your primary key going forward for all API calls instead of username as it is today.
Which parts of chat are missing the user-id tag? I can investigate those with the chat team.
@3ventic I’m going to ask the team about having the root return a user ID. Seems like a sane thing to do. You could use search/channels with the caveats I’ve mentioned in previous answers. Again, trying to figure that out with the team.
I’m going to transform some of these into FAQ questions and update the OP. Thanks for all the great questions! Helps me think through these things and chat with the teams internally.
1 Like
The chat channels themselves are not identified by number-ids, they’re usernames. So for example to join a chat you do “JOIN #{{username}}” and not “JOIN #{{ID}}”
EDIT: I guess adding a room-id tag to the ROOMSTATE message could solve most of it, since any PRIVMSG has a room-id already. Though if the id of a chat room changes after you’ve joined it, the change can’t easily be detected. Unless a specific event is sent from the server to the room that has changed.
So, is there a up-to-date version hosted anywhere you know about?
My concern isn’t the v3 channels/USERNAME (which will be deprecated and gone at some point) endpoint but the v5 channels/ID endpoint with the current root only returning the username and not the id. So I basicly have the same problem as 3ventic. Search right now would need a whole implementation of cursor and stuff as well as matching all results as you can’t always be 100% sure the user is returned on the first page (my username when searched for is on second place for example), just for the single task to get the logged in users id.
So I’m fine if at least one of this gets implemented (best would be both):
- Return UserID beside Username on https://api.twitch.tv/kraken/
- Return exact match as first result on search endpoint
In its github repository.
https://github.com/justintv/twitch-js-sdk You sure? The last code-changing commit was like 4 years ago
Yes.
@moocat Thanks for the info! I’ll ask the chat team about these changes.
@Wolfspirit Thanks for the clarification! Bringing all this info back to the teams responsible for those endpoints.
@Jaxel You’re seeing this on v5 authorization?
Okay, so in v3, if I wanted to find out what channel a user was subscribed to, I would go to:
https://api.twitch.tv/kraken/users/+$USERNAME+/subscriptions
In v5, I would now do…
https://api.twitch.tv/kraken/users/+$USERID+/subscriptions
I’ve gotten this all working so far and it seems to be fine. However, I now have a followup question to this change. In v3, if I wanted to find out who subscribes to a specific channel, I would go to:
https://api.twitch.tv/kraken/channels/+$USERNAME+/subscriptions
Has this endpoint changed at all for v5? And is there documentation anywhere for v5?