The creator dashboard available to broadcasters has a section with Streaming Tools that helps them identify what third-party tools can support them to achieve a high-quality stream.

The same experience should be available on the dev site so new developers can find which third-party tools they can leverage to build a top-notch Twitch integration.

For /moderation/banned and /moderation/banned/events.

Right now there is no official way (there is an undocumented endpoint) to determine whether a stream is sub only or not. Subscriber only status prohibits a lot of people from interacting with the stream, so it'd make sense for applications to be aware of such a state.

It would be convenient to have the ability to query Bits transactions based on broadcaster id and user id. This is extremely helpful for Extensions with lots of transactions and saves on calls to the API that would be necessary for paginating until the desired transaction is found.

See https://blog.twitch.tv/channel-moderation-tools-in-chat-4188af21dbf9 for details.

Add subscriptionStatus to extension JWT. Currently subscriptionStatus is in Twitch.ext.viewer. With it in the JWT, it can be verified by an extension backend.

I'm looking to add functionality to an extension where all bits count but bits within the extension have a weighting against those that aren't. I have my own bits transactions through the transactions endpoint but at the moment I have to ask for the scope separately. As my extension is already asking for the `channel:read:subscriptions` I thought it may be a good option to add this as an extra scope to ask for or possibly ask for within the same auth loop as the subscription read

A user's created timestamp is not yet available through Helix. The updated timestamp is personally less useful but would be nice for consideration.

We would like subs tenure in Helix in order to use this for merch extensions providing tenure-based merch options.

Get Streams does not denote if the stream is mature or not.

Some third-party developers request id access on their Extensions just for the purpose of getting a viewer's username to build a more personalized experience. The only way to do so is by relying on the Helix user endpoint on their EBS. The Helix team already modified any payload that has a user id to also deliver a username and save developers the extra step of using the /users endpoint, so it's natural for Extensions to follow that path.

Partners get a verified badge, it would be nice for published developers to get a badge too, maybe after a certain usage requirement of their extension, like how partners have to hit certain limits to become partner, maybe enough usages or page views of the extension will get a dev a badge.