Zetwitch is useful for downloading videos and clips

I honestly don't know how I can make this any clearer.

This is NOT sensitive information. It is publicly available (and always has been) to everyone in the world whenever they view a Clip on Twitch.

This information is not exposed in the current implementation of the Twitch API under the Clips endpoint.

This information used to be available with the old v5 API under the Clips endpoint.

This is a very important issue to many of us that RELY on that information.

** All we want is a response field called "video_offset" that tells us how many seconds (integer) into the video (specified by the existing "video_id" field) the start of the clip occurred. **

If you're worried about overhead, you're in luck! We just want the raw integer without any fancy hours/minutes/seconds formatting, and you already have this information available in your database.

If you're worried about it interfering with people tab-completing the field name, you're in luck! "O" comes after "I", and that isn't even something that you need to worry about.

If you're worried about this information being used negatively, you're in luck! If the streamer doesn't want something available, they already have the option of restricting/deleting clips or deleting the VOD, which would make the offset information useless (since you need to call the Videos endpoint to see what time the VOD/broadcast started).

A good addition to the Clips endpoint would be to have a "Total" field in the json response as well just like the "Get User Follows", this way it's better for bots or whatever tool that calls the endpoint to know when the end is.

I'm having a very hard time believing that there are negative use cases that are specifically enabled by having the offset information available. As far as I can remember, this information has been available since Clips launched and is STILL used for functionality on the Twitch website. If you insist that this is an issue, then VODs as a whole are an issue.

Since you guys didn't share details on how it can be used negatively we can't suggest solutions as a community. The only one I can think of is people recreating entire parts of vods from channels with lots of clips but one could just easily download the content live by scrapping the content.

Also, please consider the negative parts of not including it. E.g.: More people web-scrapping content for the offset or making twice as many clip requests (one for the clip and another for the graphql api) for getting it.

Anyway, I hope you guys can find a way to mitigate the negative parts while still letting us to know when they ocurred. It really has good use cases.

Looking forward to this.

We wanted to provide further context regarding this request as it is the most upvoted suggestion. There are several great use cases for providing the offset of Clips (including those above), but there are also ways in which it can be used negatively. For that reason, our initial decision was to no longer provide this information. With your feedback provided here, we are actively evaluating how to balance enabling good use of this information for creators while negating its potential for abuse. The status will be updated when we can share more information.

Any estimate on how many years out this is? I'll be sure to mark my calendar...

It seems this was looked at back in April and Twitch decided within 30 minutes they wouldn't be adding it. Meanwhile developers have been supporting this for months with no further response.

Twitch has been under fire recently, from its own leadership even, for losing touch with the community. They claim Twitch has been focusing on releasing new features, like paying to artificially promote channels and providing further incentive for streamers to run more ads, over supporting what the community actually wants.

Part of the solution might be paying a little extra attention to the developers and providing the tools they need to create supplementary features to support the community more directly.

Or you could keep putting maximum effort into brutally milking the cow... just remember you need to at least keep it alive, if not content, for that plan to work.

Twitch has shown time and time again that they have outright CONTEMPT for 3rd party developers trying to provide valuable services for their site (for free).

Any other company would be lucky to have a dedicated community of developers providing this kind of work for them for free.

I have been forced to go ahead with placing a notice on my site explaining the loss of functionality along with a link to this UserVoice. Including the original post, Twitch has had over 2 YEARS to implement this.

1 day away from the shutdown and no mod has ever answered this even though it is the most voted idea. I am a developer and adding one field should be pretty straightforward but if the Twitch is incompetent to the point that they can't even scope this out, I am available for hiring :)

We are less than a month away from shutdown, and this vital and critical feature has still not been implemented, very disappointing.

We need this, right now with the state of helix there is no way to link clips to their corresponding VODs. Clip API is virtually useless without context. Even the clip viewer on Twitch needs this to get the link to the video and the chat messages of the corresponding timestamp.

Please, reconsider bringing this feature back. This is so basic that the removal of this feature could lead to increase rates of web scrapping, with negative repercussions for all of us.

Edit to add my use case: I need to get the clips in a time range in the order that occurred in the stream and remove the duplicated ones

Agreed, this is an extremely important feature that has no possible workaround once v5 shutdown happens.

I'm baffled as to how this still isn't implemented when we're so close to v5 shutdown.

Go to any recent clip page on Twitch and note the "Watch Full Video" button. That is making use of the type of information we need in the API. It's available in the v5 API, but not in the Helix API.

The 'created_at' response field is NOT a "good enough" alternative because it has no relation to the ORIGINAL MOMENT IN TIME FROM THE BROADCAST that the clip is a video of. A clip can be created up to 2 MONTHS after the original broadcast.

As an example: With the v5 API I can easily tell if a clip is a duplicate of another one made by someone else that covers the same range of time. With the Helix API this is literally impossible.

I just can't think of any justification for not including this information in the response.

I don't know... Is getting clip context really that valuable? /s

Please allow me to gratefully exhort Twitch to add this feature to the Helix API. I'm experimenting with ways to synthesize multiple-angle RP situations to try to make the RP experience more accessible and easier to create. If the current API is deprecated before this feature is added, my efforts will be pretty well stymied.

The way this works with the Kraken API is not without its quirks, but even so, it is vital to a whole catalogue of roughly synchronous use cases that don't require absolute precision. The application I'm building to enhance role-playing streamers' and audience members' experiences really won't be possible to maintain without this feature (or implementing some sideways and expensive way of simulating it), and there's a whole swath of unexplored territory beyond which will be much more difficult to explore without it. Thank you very much for your consideration.

The importance of being able to fully associate clips and videos to one another for applications not being supported yet is worrying. The use cases for this endpoint is one that is very much needed and with the functionality already being supported in v5 it doesn't make sense why it can't be supported in Helix.

With the announcement of the upcoming shutdown of the v5 API, I'm appalled that something this essential still hasn't been implemented. To give you an idea of how important it is, *Twitch itself* REQUIRES this information in order to have the "Watch Full Video" link on clip pages.

Without this information, my service (StreamXRef) won't be able to use clips as a cross-reference point since there would be no way to know when in the video the clip occurred.

My use case for this is that I would like to be able to show clips in the order that they naturally occurred, and not the time that they were created

Yes please!
This is the only missing piece of data that holds us back from migrating away from the old api.
We're using it for clip deduplication and to recreate urls.