Add number of months subscribed to `/subscriptions/<user ID>` endpoint


currently the only way to track user’s subscriptions is to have a bot listen to certain events in chat. This has several problems:

  • If the user doesn’t press the share button, the subscription is missed.
  • If the user subscribes while the bot is disconnected from chat for any reason, the subscription is missed
  • Initial subscriptions require parsing of “magic” textmessages by a “magic” user (twitchnotify) in chat, and the messages don’t include the user’s id, making it potentially problematic with name changes.
  • some subscriptions cause 2 chat events, while others just cause one. For example, sometimes the “xyz just subscribed (with Twitch Prime)!” is the only one, while at other times it is immediately followed by another “xyz subscribed for X months in a row” message.
  • When buying X months of subscription in a row, the user can immediately share its Xth resubscription, even though he just started his firsth month. Consecutive months then count the current subscription’s month backwards (second month saying it’s the (X-1)th anniversary for example)

For those reasons, I propose adding a months field to the subscription object of the API endpoint GET<channel ID>/subscriptions/<user ID> (Docs Link).

That endpoint already includes a created_at field, but it cannot reliably be used to get the number of months, because one consecutive subscription chain can have up to one month of pause inbetween.


It would also be awesome if you add “has_turbo” and “has_prime” field. When you make giveaway and can’t tell if this user subbed for their money or used free subcription just for this giveaway, it is very bad

1 Like

Why would it matter if they paid $5 for the sub or whatever prime costs for that? Both end up earning the broadcaster the same amount.

1 Like

I agree with you - we definitly need a months property.

Also the prime/turbo info could be used for custom animations - maybe some cool prime smiley. It’s public in the chat anyway - so why should the api not provide this information?

On this note, they should also add a updated_at property, which is set to the sub/resub date - so you can request subscriptions ordered by updated_at, which is the most important request i personally have for this endpoint.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.