Currently the management of extension SKU's is only done via the Developer Rig.

Since the rig is an optional, many people are developing / testing without using it & the fact that its a development environment, its a strange place to place/manage production SKU's. These would be better managed from the platform itself under the Monetization tab of each Extension.

Allow developers to sign up for a specific time slot where they can rely on an extension reviewer to review the extension.

Provide a sandbox to test Drops integrations.

The current Helix endpoint doesn't give the broadcast ID, so there's no way to grab which broadcast the VoD is from.

Make the docs closer to OAuth specs. The docs say to send parameters to /token (and /revoke) in the query string, but this is non-standard. Twitch supports the parameters in either the query string or request body.

The documentation should prefer the standard approach of sending parameters in the request body.

https://dev.twitch.tv/docs/extensions/reference/#send-extension-pubsub-message

The docs say Valid values: "broadcast", "global".

But, the target 'whisper-opaqueId' to send "per user" pusub message is missing.

From: https://github.com/twitchdev/issues/issues/69
Brief description

Some endpoints return a 204 code no content.
But this is only highlighted in the example responses and not in the "main documentation"

For example

https://dev.twitch.tv/docs/extensions/reference#send-extension-pubsub-message
https://dev.twitch.tv/docs/extensions/reference#send-extension-chat-message

Each endpoint documented could be extended to include usual HTTP response codes.

Expected documentation

The expected response code for success when theres no body response
Common non 2xx codes for the endpoints

From: https://github.com/twitchdev/issues/issues/68

Docs location: https://dev.twitch.tv/docs/irc/msg-id

bad_ban_global_mod & bad_timeout_global_mod are gone for as far as i know (ref: https://blog.twitch.tv/en/2018/12/13/thank-you-global-moderators-4d44cfccf22/)

Missing notices for vip events (vip_success, unvip_success, no_vips, bad_vip_grantee_banned, bad_vip_grantee_already_vip, usage_vip & bad_unvip_grantee_not_vip Might have missed some.

First line says "These tags apply to both the" and than only names one thing.

usage_untimeout has "/raid <username>" in the message.

From: https://github.com/twitchdev/issues/issues/65

Brief description

https://dev.twitch.tv/docs/api/webhooks-guide

> Limits: By default, each client ID can have at most 10,000 subscriptions. Also, you can subscribe to the same topic at most 3 times.

Seems to be ambiguous to a lot of developers, they seem to think the that "3 times" means they can renew it 3 times then they are SOOL

Expected documentation

> Limits: Each client ID can have at most 10,000 subscriptions. Where you can have 3 active subscriptions to a topic at the same time. Where an active subscription is defined as a topic/callback pair.

From: https://github.com/twitchdev/issues/issues/59

Brief description

Mod Change and Channel ban Change events don't note the required oAuth scope needed for the topic

https://dev.twitch.tv/docs/api/webhooks-reference#topic-moderator-change-events
https://dev.twitch.tv/docs/api/webhooks-reference#topic-channel-ban-change-events

Expected documentation

Add, (similar to Topic: User Changed)

Authentication

User Access Token must have the `moderation:read` for the user in question

Additional context or questions

https://discuss.dev.twitch.tv/t/webhook-topic-for-channel-ban-change-events-and-moderator-change-events-doesnt-require-oauth-scope/24105

From: https://github.com/twitchdev/issues/issues/14

Brief description

https://dev.twitch.tv/docs/api/webhooks-reference

the hub.topic section is out of date, in the JSON Body Parameters

Expected documentation

Just changed it to something like "refer to later in this docs for the available topics"

A great many Ideas/notes and stuff from the Developer discord was collected and thrown into a Google Docs

https://docs.google.com/document/d/1dxx04pp6VVqY9s9JRcVP3w9keBHrRR5LB3Q043McS1Q/edit?usp=sharing

Covers
- CRUD store items
- Fetching/updating points values
- handling store redepmtions
- Stuff about webhooks
- Stuff about points in extensions (see also https://twitch.uservoice.com/forums/310213-developers/suggestions/38874571-channel-point-transaction-in-extension )

Throwing it here so it's here as well as already sent to Twitch via Dev Advocacy

As noted here

https://help.twitch.tv/s/article/lifetime-subscriber-guide-for-partners?language=en_US

> Lifetime Subscribers are a unique benefit for Twitch Partners. Lifetime subscriptions do not generate revenue or additional subscription points.

No where in the subscribers API is a given sub tagged as lifetime.

So whilst we can math the subscriber points from helix, we can't discount these lifetime subs from our count.

Extend the subscribers API to flag as lifetime, (or provide a seperate endpoint)
And provide a API to fetch the Sub Points without having to iterate all pages.

It would be nice to provide mixpanel support too for analytics for some cases.

If you call GET https://api.twitch.tv/extensions/<client ID> you get a JSON back with the information about the extension. This is currently undocumented, but it would be a real useful took for discoverability and management, but being undocumented, it wouldn't be wise to use in a production environment. If this endpoint is planned to be kept, can it be added to the documentation for our use?

Include the displayName in the javascript helper without asking any special permision or without doing any special function (like using bits).
This value it's only available if the user send bits and the transaction get complete.

Currently, I find the docs hard to get through, although most documentation is there. It would be nice if you can go to the part of the docs that you might need, at the moment you are having a choice. For example when choosing what type of extension you want, that it will have a link to that specific documentation. Let's say you have chosen Panel, you then get a link to a/some of the example repositories for a Panel, the test channel, and a link to the documentation for creating a Panel.