'created_at' inconsistency in Get Channel Subscribers

API
1

There’s a disconnect between sub length shown in chat badges/sub streak length on resub and the data returned by the API. arviu_ow currently has the 6 month subscriber badge, but this is reporting that their current sub length is much shorter.

Would it be possible to either modify created_at to give an accurate initial start date for this streak or to add a new field that accurately represents when the user initially started subscribing to the channel on their current streak badge?

{
    "_id": "7263de2f9a8d290fc941683234562e6dc3f49f0c",
    "created_at": "2018-09-18T17:07:17Z",
    "sub_plan": "1000",
    "sub_plan_name": "Channel Subscription (ml7)",
    "user": {
        "_id": "167287757",
        "bio": "",
        "created_at": "2017-07-29T14:15:40Z",
        "display_name": "arviu_ow",
        "logo": "https://static-cdn.jtvnw.net/jtv_user_pictures/d5bf12ac-3e6b-43eb-abb9-591ccabb73d3-profile_image-300x300.png",
        "name": "arviu_ow",
        "type": "user",
        "updated_at": "2018-11-22T23:19:26Z"
    }
}

arviu_ow has been subbed to ml7 for 2 months, 5 days
arviu_ow has been following ml7_ow for 8 months, 2 weeks, 6 days, 1 hour, 13 minutes, 32 seconds
2

This a long standing complaint with the subscription APIs since they do not currently provide sub streak data. The valuing being returned is the date the user last started a subscription to the channel so if they cancelled and resubbed to change payment method, tier or simply took a break with the grace period it will return a shorter period.

Hopefully when subscriptions are added to Helix this data will be provided.

1 Like
3

Amen.

4

I don’t want to wait for helix, I’d like to have access to the data now. It’s a bug pure and simple. Twitch has access to the streak data or else they wouldn’t be able to display streak badges or update them on anniversaries, they’re CHOOSING to publish inaccurate data to the API.

5

If you’re just looking for their current badge level, you could use the endpoint https://api.twitch.tv/kraken/users/USER_ID/chat/channels/CHANNEL_ID

6

It is NOT a bug, it’s just not the data you want. The created_at field is correct, as has been said previously, it’s just it’s the date of when that subscription object was created in the database, not of when the current sub streak was created. That field was never intended to be used as a way to determine a persons current sub streak, so just because it’s not what you want doesn’t mean it’s inaccurate data.

For right now your options are quite limited, you can use chat badges or log sub messages in chat to get an idea of when a person started their streak but nothing accurate. If you want to know the specific timestamp a person started their streak you’ll have to hope it’s included in Helix (and there’s no confirmation of what will be in Helix).

7

The subscribers endpoints also predate sub streaks so they were never updated to add that information.

8

@sundheden the endpoint you’re giving has the same information as the one I’m hitting.

@george
That’s materially incorrect. v5 was introduced sometime mid 2015 as judged from google trends, sub streaks have existed since Jan 2015. Kraken hasn’t (to my knowledge) existed in production since Jan of 2015. Regardless, just because your tire’s been flat for 3 years doesn’t mean you don’t change it before going for a drive.

@Dist, if the purpose of the API is to provide useful data to developers and that data is materially incorrect and not fit for purpose (as in created_at not matching sub streak start date) that’s pretty much the definition of an API bug. I can say with confidence that the majority of the consumers of this particular api have absolutely zero interest in when the subscription started from a billing standpoint, but do have interest in when it started from within the context of a sub streak, considering sub streaks have been a thing for nearly 4 years now.

Please note that I said that if twitch wanted to add the object that they’re referencing to actually calculate badges/streaks to this particular endpoint, I’d be fine totally with that solution as well. created_at, however, is currently only valid from a backend billing context, which makes it wildly inaccurate at best for most API consumer purposes and a potentially embarrassing data leak at worst (in the case of someone having billing/financial issues).

Regardless, twitch has the data and they’re not publishing in the place where logic dictates it should be.

9

And long before v5, there was v3, which v5 was almost entirely based on with the main exception being that v5 shifted the focus to using an id in request paths/querystring params rather than a username. The v3 docs for that subscriptions endpoint (which is the exact same url BTW as the request in v5) goes back to feb 2013, and if there was documentation prior to that then that was before my time here, either way that created_at field has existed prior to streaks as George has said.

Again, just because it’s not the data you want, doesn’t mean it is incorrect. Perhaps the docs could do more to explain the purpose of that field so as to cause less confusion (even some of the most well known dev companies on Twitch have made mistakes due to misunderstanding that endpoint, so that does show the docs leave something to be desired, but thankfully that’s being worked on and there’s even a dedicated Docs person at Twitch now!).

As you can already see from the changes going forwards from v5 to Helix Twitch is already making great efforts to remove both redundant data and data with minimal usefulness (while the notion of created_at being a bug is wrong, its usefulness is certainly limited and devs have put forward better suggestions that would be more useful in Helix).

As has been said, you’ll have to wait for Helix. Feel free to submit your suggestion to Twitch yourself though if you like: Twitch API Feature Requests (please use twitch.uservoice.com)

10

Well, either the docs are broken (bug) or the data’s broken (bug), or both are (bug). Take your pick, but any way you look at it, it’s unexpected behavior (bug) because it’s outputting data that doesn’t make sense to query for (aka, a bug). Why haven’t Twitch’s developers managed to fix this thing that relates to a 4 year old feature that people have been complaining about for at least the last year when it shouldn’t be more than an hour’s worth of work? Whether this endpoint in v5 is a copy/paste of v3 or not is immaterial. Will it hurt existing applications to add another key or correct the value? Probably not. Will it provide benefit to people who want this sort of information? Probably. Is it currently sending data that is both irrelevant and completely unexpected? yes.

Oh, right, you want us to wait until 2021 or whenever Helix is complete to complain about actual issues in twitch’s api that prevent us from being able to track streaks (a 4 year old feature) today. SeemsGood

For reference: “A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.”

11

I guess you’re probably furiously typing about how the length of a subscription isn’t part of the data originally designed into the endpoint. But if that were the case, why would there be a created_at at all?

12

As I said, just because you didn’t understand what the field is for doesn’t mean it’s a bug. Poor documentation is not a bug, it’s just, well, poor documentation lol.

I don’t speak for Twitch, but it is understandable that it would be a mismanagement of resources to develop a feature for a deprecated API. It’s more efficient for the devs to focus on Helix, especially when what you’re asking for isn’t going to be largely used (many devs have already migrated to Helix, and those that haven’t are unlikely to spend development time on a deprecated endpoint). Everyone else has their own workarounds and solutions that are appropriate for their individual use cases that will be sufficient until the endpoint for Helix is released.

Until then, you just need to be patient, you’ve made your point known, I’ve linked how you can submit feature requests so there’s always that too :slight_smile:

13

So you’re already migrated to an API that isn’t fully documented or feature complete? Interesting.

Please tell me more about how you can both not speak for Twitch and also assert with authority that something isn’t a bug at the same time.

14

It’s not a bug.

created_at shows the payment start date for the subscription.

It is not representative of the users SubStreak or badge status.

There is no official/documented API end point to obtain the streak data.

The “missing” streak data is a known issue and hopefully Twitch will make this data available via the API at some point.

1 Like