I’m using the webhooks method to monitor the streams status but I’m running into some issues.
When a stream goes up, twitch sends me a notifcation including the payload as described in the docs. But when the stream goes offline I don’t get anything else than an empty array. Also $_GET, $_POST are both empty. How I’m supposed to find out which channel just went offline when I’m subscribed to multiple channels, I don’t see a solution right now on how to distinguish those notifcations?
Also I was wondering about the API limit. Let’s say I subscribe to a stream event and set the lease time to 5 days. What happens if I use a cronjob that renews the subscription every 24 hours. Does this count towards the API limit as a “new” subscription? Do I have to explicitly unsubscribe before resubscribing or is done automatically when I subscribe to the same event and channel again?
The stream down webhook returns an empty array because it mirrors a call to the API, which would also return an empty array when a streamer is offline.
The header contains a link field which does contain the URL you subscribed to, so it is possible to parse that and get the user ID.
Alternatively, what most devs are doing is using a separate callback for each webhook, eg, myApp.com/webhooks/streams/123456; and using a single function to handle POST’s to myApp.com/webhooks/:topic/:id and determining the topic/id of the incoming post based on the URL parameters. Depending on what language you are using, it may be easier for you to use querystring parameters in the callback, eg myApp.com/webhooks?topic=streams&id=someID
Having unique callbacks for each subscription makes things so much easier.
As for the API limit, whenever you are renewing a webhook that already exists, it just overwrites it so wont impact your total number of subscriptions. Although having a 5 day lease and renewing every 24 hours is a bit excessive considering everything Twitch has in place to ensure webhooks persist (and I believe they are also considering an endpoint to query what subscriptions you have up too, for extra assurance). Subscribing to a webhook does use your Helix limit so also keep that in mind, with a large number of subscriptions so might want to stagger them so they’re not all renewing in a short space of time.
Oh, well that makes sense. Obviously this approach is pretty painless, I’m going to definitely implement it like this.
Regarding the API limit I was just curious, I’m not planing to implement it as described in my question
