I am getting 202 in response and when I try to get list of my subscriptions by making GET request to https://api.twitch.tv/helix/webhooks/subscriptions then I am seeing that new subscriptions have been added but when I follow user <user_id>, I don’t get any sort of notification from twitch.
I am also sending the challenge back in response to GET /twitch/webhook that my web server receives when it requests for a subscription, and I think this part is also working fine as I am getting proper list of subscriptions from twitch API.
And I have confirmed that my server is listening to /twitch/webhook for POST requests.
Yes I am using NGROK and yes it was tunneling, I can say that because I sent a dummy POST request on the https://<ngrok_url>/twitch/callback and I saw that request getting handled by my web server.
I will test it with some big twitch streamer and let you know.
My entire flow. step 1. sending request to twitch to for subscribing.
step 3. I am getting getting GET /twitch/webhook, and once I send the <challenge_string> that I get from query string itself then I see a new entry when I fetch list of my active subscriptions from twitch.
step 4. Whenever I follow or unfollow the channel that has it’s id set to <twitch_channel_id> my web server should receive POST request from twitch with relevant data (which is not happening right now).
Skip the 200’s and just OK and send the challenge string. Shouldn’t be an issue but express will handle the 200 for you.
You do not get unfollow notifications
You might be unfollow/refollowing too quick and the API didn’t clear your follow in order to re-notify for the refollow. Thats why we test follows on “real” data rather than trying to mock/force Webhooks to send with tests
Stream up will take 2/3 minutes. (To confirm that the stream is in helix streams end point
Steam down on average takes 6 minutes. (To confirm the stream is no longed in helix and to confirm that the stream down was a stream down and not a OBS/XSplit crash)
The webhook. when sent is a “duplicate” of the data in the same URL of the topic you subscribed to. So the data on that URL matches whats in your payload. So it has to wait to confirm stream stability and for the Helix Cache to clear
Twitch are working to reduce the delay, but there will always be some delay as by design it gives some time to allow for the stream to come back up just in case it was a brief outage rather than the streamer going offline by choice.
There is no paid service and no 3rd party could do better as any 3rd party source is just getting the data from Twitch themselves anyway.
If you need the fastest possible notifications that a stream has gone offline, you’d have to work with each individual broadcaster you need data for and run an app, or OBS/XSplit plugin on their end that will detect when they stop streaming and send you the data directly.
No, if it was quicker, how do you intend to handle
a) OBS/XSplit crash and the broadcaster restarting the stream, which means you get two extra webhooks for no reason
b) How do you intend to handle how Twitch handles caching on the API?
It is as low as it’s gonna get. And it has got lower than it was when Twitch first bought out webhooks. Might see a minute of improvement.
But still gotta account for Software crash which is the primary reason for the delay.
How? There is no way to make this quicker.
Because it has to account for
a) Software crash
b) API caching.
if you paid for it
it would still be 6 minutes delay on a stream down
Even then you might still need to account for crashes which means you’ll suddenly stop getting heartbeat data (in the case of OBS).
Was it a stop? Was it a crash? Did the end stream event(s) correctly fire? Did the broadcaster hit stop in order to restart to change bit rate?
Which then means you need to debounce stream restarts, which webhooks, essentially, do for you.