How fresh can I expect the subscribers endpoint data to be?

[stav]

I am working on a small project for a friend’s stream and I need the data to be as recent as possible.

Currently trying to get the latest 10 subs. Recently for example, there has been sub and the response hasn’t updated with that over an hour later.

Do I need to go the webhook route if I want reliable recent data?

[BarryCarlyon]

@stav

Currently trying to get the latest 10 subs. Recently for example, there has been sub and the response hasn’t updated with that over an hour later.

Never had this issue myself, I’m doing the same. Is it consistently this bad? Are you using v3 or v5?

@stav

Do I need to go the webhook route if I want reliable recent data?

Theres no subscriber webhook (yet)

Personally what I do, is I seed with a DB fetch 4 times a day and then use USERNOTICE or PubSub to collect Subscription events as they happen

[stav]

Is it consistently this bad? Are you using v3 or v5?

I am using kraken urls, according to the docs would that be v3? It seems to happen somewhat consistently.

More insight: Does the subscriptions response order stuff by the second they clicked subscribe or when they share the message? Same question for the PubSub. We want to have access to this list hopefully within seconds or minutes of the subscription happening.

Usually if they don’t appear instantly, they will appear a few minutes later. The one extreme example that I’ve seen so far is a tier 3 sub that happened around 6/22.

Whats weird is that I checked again yesterday and the response still returns the date of subscription as 5/22 when they resubbed on 6/22. It hasn’t updated days later. Maybe it has to do with payment date vs sharing date? Though they still claim they had just subbed recently.

PubSub seems like a good solution!

[Dist]

@stav

Whats weird is that I checked again yesterday and the response still returns the date of subscription as 5/22 when they resubbed on 6/22. It hasn’t updated days later.

I believe you are misunderstanding the created_at field in the subscription objects. When someone resubscribes it’s still the same subscription, the date on the created_at field wont change under normal circumstances.

So for example, if a user called foo is a brand new sub, it will create a new entry for them, but if a user called bar resubscribed at the same tier they were previously, then nothing changes as their subscription object remains the same.

This endpoint is not intended to be a list of subscription events, just a list of all subscribers.

Also worth noting, is that there are certain situations which can cause a change to a subscription object, these include a change in payment method, cancelling a sub and resubscribing, or subscribing at a new tier. And in the case of subscribing as a different tier, it’s possible for the user to show up in the list multiple times, as both the old tier and the new tier so keep that in mind. Because of this the created_at field is an unreliable way to determine length of sub.

If you want a real-time (or close to it) way to get subscription events, use Pubsub, or Chat, or when it’s released the webhook.

[stav]

Ahh I see, that explains the inconsistencies I’ve been seeing I think. It seems that it was a coincidence that the list had been somewhat correct until now, minus some cases. I will go the PubSub route.

Thanks guys!