“Get Hype Train Events” API endpoint - “id” query parameter deprecation

With the removal of WebSub-based webhooks last year, the optional event id query parameter for the Get Hype Train Events Twitch API endpoint is no longer meaningful. As a result, this query parameter is considered deprecated and will no longer function starting on or soon after April 4, 2022.

What’s changing?

The “Get Hype Train Events” Twitch API endpoint has an optional query parameter for id that will return one specific Hype Train event rather than the full list. On or soon after the date above, this optional query parameter will be ignored. The result will be a successful request to the API endpoint as if id was not specified.

id will not be removed from the API endpoint’s response object. At a later date, this value will be generated by a different system than the one WebSub utilized, but it will remain a string.

Who will be impacted by these changes?

Any developer currently adding the id parameter to their request will be affected. We’ve identified that the usage of this parameter is low and expect a low impact.

What action needs to be taken?

If this parameter is being used, application logic should be updated to not use id and/or expect the first page of Hype Train events to be returned instead.

The deprecation reason appears to focus on WebSub, but isn’t id also present via EventSub?

1 Like

In my opinion:

Sure, but with

After 5 days, if no Hype Train has been active, the endpoint will return an empty response.

The ID parameter doesn’t make sense since if you missed the train data in real time it doesn’t make sense to look it up by ID since you won’t have the ID. So you would just get all the recent trains.

ID just helps hype train data consumers deduplicate and correlate data of a train together which is why it exists in the data.

I also imagine Twitch has looked at the API call logs and fine that basically no one uses the optional parameter anyway. And if an EventSub consumer wants to look up the recent train you can just call the endpoint anyway and get the most recent trains wihtout needing to know the ID to look up a specific ID.

TLDR: due to the time constraint for “history” on the Endpoint the ID parameter doesn’t make any session and CPU cycles/stability can be moved elsewhere

1 Like