Summary
EventSub enforces a limit on the maximum number of subscriptions a developer’s application can create, which today defaults to 10,000. Twitch is changing this logic so the maximum number of subscriptions automatically grows with your application’s user base.
Motivation
Developers’ applications have a default subscription limit of 10,000. When a developer needs an increased subscription limit, they first need to make a request to Twitch and justify the increase. These requests require a review and can take a considerable amount of time to process.
Even after a subscription limit is increased, the limit is still a static value. If a developer’s application continues to grow or if they wish to take advantage of more subscription types, they will need to create more subscriptions and thus may need to request another limit increase. This adds friction to application growth and development.
We want to reduce friction on developers by automatically increasing the number of subscriptions their applications can create as their user base grows.
Proposed Solution
If a user has authorized your application, your application can create unlimited EventSub subscriptions for that user.
Note that this proposal ONLY changes how EventSub determines whether you’ve created too many subscriptions or not. Everything else is staying the same:
-
This proposal does not change authorization requirements for subscriptions. If a subscription type requires an OAuth scope, the application still must possess that scope to create the subscription.
-
EventSub will still forbid creating the same subscription more than three times. A subscription is considered a duplicate if there exists another subscription with the same type, version, and condition.
Example
Suppose a developer wants to create three subscriptions for every user:
- “channel.update” (doesn’t require any OAuth scopes)
- “channel.follow” (doesn’t require any OAuth scopes)
- “channel.cheer” (requires the
bits:readOAuth scope)
User A has granted authorization to the developer’s application and that authorization includes the bits:read OAuth scope. Then the developer could create all three of those subscriptions without impacting their limit.
User B has granted authorization to the developer’s application, but the authorization only includes the channel:moderate OAuth scope. The developer could create subscriptions #1 and #2 without impacting their limit, however could NOT create subscription #3 (they’re missing the required OAuth scope).
User C has NOT granted authorization to the developer’s application. The developer could create subscriptions #1 and #2, but it WOULD impact their limit. They could NOT create subscription #3 (they’re missing the required OAuth scope).
This is summarized in the following table:
| channel.update | channel.follow | channel.cheer | |
|---|---|---|---|
Authorized with bits:read scope |
No Impact on Limit | No Impact on Limit | No Impact on Limit |
Authorized without bits:read scope |
No Impact on Limit | No Impact on Limit | Unauthorized |
| Not authorized | Impacts on Limit | Impacts on Limit | Unauthorized |
Detailed Changes
We will update subscription payloads to clarify which subscriptions impact your limit. To do this, we will add the following vocabulary:
-
Cost: How much the subscription counts against your limit. Subscriptions cost 0 if the user has authorized your application; otherwise they cost 1.
-
Total Cost: The total cost of all of your subscriptions for your application.
-
Max Total Cost: The maximum value of Total Cost allowed for your application.
Let’s consider an example where a developer’s application has been granted authorization for user 123, but not for user 456. Thus subscriptions for user 123 will have “cost: 0” but subscriptions for user 456 will have “cost: 1.”
Here’s what the “List Subscriptions” API response would look like:
{
"data": [{
"id": "26b1c993-bfcf-44d9-b876-379dacafe75a",
"status": "enabled",
"type": "stream.online",
"version": "1",
"condition": {
"broadcaster_user_id": "123"
},
"created_at": "2020-11-10T20:08:33Z",
"transport": {
"method": "webhook",
"callback": "https://this-is-a-callback.com"
},
"cost": 0
},
{
"id": "35016908-41ff-33ce-7879-61b8dfc2ee16",
"status": "enabled",
"type": "stream.online",
"version": "1",
"condition": {
"broadcaster_user_id": "456"
},
"created_at": "2020-11-10T20:31:52Z",
"transport": {
"method": "webhook",
"callback": "https://this-is-a-callback.com"
},
"cost": 1
}],
"total": 2,
"total_cost": 1,
"max_total_cost": 10000,
"pagination": {}
}
A subscription’s “cost” will automatically update if the user grants or revokes authorization from your application. If an update to a subscription’s '“cost” causes the value of “total_cost” to exceed “max_total_cost,” the offending subscription may be revoked.
Transition Plan
EventSub will match your application’s “max_total_cost” to whatever your subscription limit is currently, which defaults to 10,000.
The “cost” field will be added to all subscriptions. EventSub will start respecting “total_cost” and “max_total_cost” when enforcing subscription limits.
We will deprecate any “limit” fields on EventSub payloads since they’re no longer used, and remove them after 3 months.
Once this transition is complete, developers will immediately be able to create more subscriptions than before, without requesting a subscription limit increase from Twitch.
". Nobody would want to use that product.