Given the fact that Twitch had to take down the follow/unfollow api's due to bot programs that are out there - my suggestion would be to have an approved set of developers that propose and showcase their applications.

This way Twitch could bring back the follow/unfollow API and any service or developer that was in violation of Twitch's TOS regarding the API could be warned and ultimately have their access and credentials removed.

Twitch Developers could review the logs of which applications were connected with BOT services and immediately shut those down rather then removing the api in its entirety and removing it for those that are using the api to help smaller content creators gain followers and viewers through content.

Kraken equivalent[1] of Get Users Follows offers a way to sort query results by either creation date, last broadcast or login name. There's also a way to sort results in either ascending or descending order. Helix however doesn't offer any ways of sorting results of your query and results are always shown descending without giving you the option to get those in ascending order.
In case you need to fetch exactly the first follow or get followers that have been live last, it becomes problematic if your query has lots of results - you'd need to paginate through all of them and then go through all of them again and sort them on your end. Please add those features to Helix endpoints if possible.

[1] https://dev.twitch.tv/docs/v5/reference/users#get-user-follows

In the new badge-related endpoints, badge objects in returned sets contain only their IDs and URLs, which compared to the only existing alternative (undocumented badges.twitch.tv endpoint announced in twitchdev forums[1]) isn't enough for things like custom chat clients that are very popular among many Twitch users.
Ever since that undocumented endpoint came to existence, we've been using it in our chat client and would at least need "description" and "title" properties that are present in badges.twitch.tv to display information about badges properly and replicate webchat's behavior. I believe both APIs use the same internal data (at least for Global Badges) and if that's possible please include more information about badges in the Helix endpoint if possible, thanks!

[1] https://discuss.dev.twitch.tv/t/beta-badge-api/6388

The v5 endpoint contains the follower's account creation date, the new endpoint (https://dev.twitch.tv/docs/api/reference#get-users-follows) does not.

Knowing when a follower created their account is very useful to moderators monitoring recent follows to keep an eye on potentially problematic users (new account could mean a previously banned user returning) or to detect mass follows from bots (which often have a similar account creation date). Monitoring recent follows is especially useful in follow-only chat mode.

While it is possible to get the account creation date from the "Get Users" endpoint (https://dev.twitch.tv/docs/api/reference#get-users) and then merge it with the follower data, it would be nice if it were in the "Get Users Follows" endpoint as well, which would reduce the amount of API requests required.

The Create Poll endpoint has optional query parameters to allow additional votes using either bits or channel points.

However, it doesn't actually allow multiple votes. This can be seen in the pubsub response which explictly states that "multi_choice" (property indicating whether additional votes are allowed) is not enabled.

When creating a poll through the web interface, it works just fine as it is created through the GQL and not the API. The GQL message also has an additional property to explicitly allow additional votes, on top of the properties that are used to either allow additional votes by bits and/or channel points.
So either the query parameter is just not documented... or the endpoint itself is flawed because like half of its functionality is just broken.

Also gonna drop the documentation link as a reference: https://dev.twitch.tv/docs/api/reference#create-poll

Feel free to hit me up in case you want additional information regarding this (or when I just overlooked/misunderstood something)

Scenario:
A viewer comes in and gifts 10 subs to the community; This fires off in theory 11 events. One event is the channel.subscribe.gift, while the other 10 are the individual channel.subscribe for the 10 users.

Request:
The channel.subscribe.gift has an id associated with its emission. Something that would benefit reactionary data would be each of the individual channel.subscribe events having a gift_event_id. If the sub was a gift, set the id to the channel.subscribe.gift event id.

Use Cases:
- A developer could choose to listen to the batched gift amount and react to that single event, then omit the 10 linked events from the chain.

• A developer could listen to the batched gift, and use the linked events as supplementary data for a visualizer

• A developer could correctly match the subs gifted in a batch to the correct batch and handle them as they see fit. Some case scenarios of multiple users gifting subs at once currently cause problems with the guestimations that you currently must do when assuming who gave who a sub.

Any developer not needing this info wouldn't be affected, nor would this be a breaking change.

Related Submissions:
https://twitch.uservoice.com/forums/310213-developers/suggestions/43241439-channel-subscriptions-to-include-who-gave-the-gift