API V5 /Users/ endpoint question/incoming issues

[Teiko_Kullman]

Hey,

Since Twitch decided to throw shovel full of crap into the fan and causing headache to big communities and services that are using username to get data ouf from Streams endpoint for example.

Would it be possible to receive same feature as /Streams/ endpoint so we can for example with 1 JSON request be able to pull from 1 to +500 names all of their ID’s at once without having to do it one by one each time we need to update something and cause alot of stress(and also possible block of client_id token due to massive stress caused by single requests)?

Reason why i’m asking is that on the Q&A someone said that they have millions of username entries which needs to be converted into ID’s and also as i’m working with community Discord Bot & Website things including Twitch API requests of online streamers from names we have in our database and if i really have to do all updates one by one with simple script it will be popping of Twitch limits instantly (else the update would take from 4 to 24 hours or probably even more).

Allowing us to request more than one name at time will make our transition so much easier because we can make better scripts for getting all ID’s at once and adding them to database or where it’s needed without having to struggle with annoying single name requests.
Ofcourse this would also require that even when V3 gets deprecated, /Users/ endpoint must be working same way to ensure our chance to actually keep getting ID’s and updating them when needed.

Here’s my second question:
When V3 gets deprecated how the … are we supposed to pull User ID from???

As Twitch states: "If your integration relies on username now, please use the /Users/ endpoint to translate from a username to an ID as shown below. → https://api.twitch.tv/kraken/users/dallas "

I tested this /Users/ endpoint with V5 and well that particular thing does it too so we must have ID instead of username … so I ask again that how are we supposed to get the ID?

Yeah sure I know that there was answer on comments about it (not for bad but it’s just simply terrible way of doing it) which was suggestion on how we could use it but how do you expect us to get 100% accurate data when query gives us correct one and several of other same looking ones?

https://api.twitch.tv/kraken/search/channels?query=statusd112&client_id=TOKEN_HERE&api_version=5

It’s just ridiculous that you are going to implement system modification which allows you to do more but in other hand slapping us 3rd party developers in the face and making our work look inaccurate/bad only because we simply cannot rely on V5 /Channels/Search/ endpoint to always have 100% exact match with limit=1.

I do apologise that this contains alot of things that can be found at Q&A topic but I just want to have seperate topic with answers only to those questions.

[Larklen]

To address your second concern, when they stated to use https://api.twitch.tv/kraken/users/dallas to pull the user ID, it is with v3 not v5 (as v5 you need the user_id)

Dallas has recognized the (large) concern regarding v5 and determining the user_id after v3 is removed in 2018, so I am sure we will see something come out for that, but in the mean time there is a way to determine the user_id in v5 however it still is not an ideal method and I look forward to what they introduce.

In v5, you can determine a user_id by using a username via:

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 - you can determine which token is correct as the others are a similar name while only one will match (or 0 if the user is suspended).

But as I mentioned earlier, that ‘workaround’ isn’t ideal and is messy so hopefully we’ll see an endpoint that returns a user_id for a given username (or something along those lines.)

[3ventic]

V5 doesn’t offer a good way to get the ID from a username, which has been the primary concern of people and will very likely be addressed soon. Keep in mind you have over a year to migrate. Constructive criticism and documentation first, then migrating production code.

[DallasNChains]

I’m closing this thread to keep everything centralized in the Q&A thread. All of these concerns have been addressed there. If you have other concerns that haven’t been addressed, ask on that thread and I’ll respond as I have been with other questions.