[BUG] Webhooks Stream Up/Down

Hello

I recently implemented the new Stream Up/Down Webhooks,

I got them to work mostly as expected, i am getting the correct stream up notifications, altough only when the user goes online, if my server starts and the user is already online then i don’t get any notification, i guess that is as expected?

The other issue i am facing with the new webhook is that i am never receiving the stream down notifications (also in the documentation there isn’t really a lot of information regarding the down part), maybe someone could clarify how the stream down webhook should behave? and if he or she got it to work correctly?

Use kraken or new API to “catch up” or get initial status

Stream downs should send a POST with a (near enough) empty body. IE the same as calling kraken/helix which returns a null response if the target stream is down. Check the “link” header for additional information

@BarryCarlyon

Use kraken or new API to “catch up” or get initial status

Yeah that was my alternative plan :slight_smile: to initial fetch all relevant users once and find out who is online/offline that way

Stream downs should send a POST with a (near enough) empty body. IE the same as calling kraken/helix which returns a null response if the target stream is down. Check the “link” header for additional information

Thanks for the info, i seem to get that down post sometimes, although it doesn’t work most of the time for me, and mostly only once directly after the initial verify call, i don’t have that problem for the stream up callback so i guess that my response handling should work correctly because my webhook is called for the up events, just the down don’t seem to be triggered for me.

As for the headers, is there a more reliable way to get the user_id for the down event? it seems as if there is only the link header from which i can parse it, but the header looks like this:

<https://api.twitch.tv/helix/webhooks/hub; rel=“hub”, https://api.twitch.tv/helix/streams?user_id=135542076; rel=“self”

which isn’t exactly the best way to send that information^^

The only thing Twitch provides to ID the payload if relevant data is not in the payload is the link header.

It probably matches the W3C spec for websub but I’d have to sit and read the spec end to end :smiley:

1 Like

Okay :slight_smile: didn’t shift throught the specs myself in detail, but i guess then there is no easier option to find out the correct id^^

I think i have setup everything correctly then^^

My other problem might still be a bug (e.q. that i don’t receive the offline message), maybe someone from twitch could clarify if there might be a problem here or if i am doing something wrong^^

To identify which id or topic a notification is for you could always use different callbacks. For example yourapp.domain/api/streams/UserID, yourapp.domain/api/streams/AnotherUserID, or yourapp.domain/api/follows/UserID etc… Then you can still use the same handler for all of them, but easily be able to see from the request URL both the topic and userid that the notification is for.

I’m not sure why you’re not getting stream down notifications though, from my testing I’ve been getting the empty array to indicate the stream is offline, much like you would get from polling the API.

3 Likes

@Dist That is a great idea thanks :slight_smile: didn’t think of that i guess i was search for the solution at the wrong end^^

Hmm strange, i am really not sure what i might do wrong here, since it is the same callback and the other one works without a problem, maybe it is related to my network and better once i deploy it on my staging server (i am currently testing on my local dev machine + port forwarding) <- sometimes it seems as if twitch takes quite some time to send me the notifications maybe the stream offline callback works with different delays or something

Could be, I’m yet to use the stream up/down so can’t comment.

But when I do, I’m still gonna be using kraken/helix. So if a webhook is missed I’ll still get kraken/helix +3 mimutes later

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