Getting Golive Event for Changing Game

We have a bot, which listens to the webhooks for a streamer going live:

async function subscribe() {
  return fetch('', {
    method: 'POST',
    body: JSON.stringify({
      "hub.mode": "subscribe",
      "hub.topic": `${process.env.TWITCH_USER_ID}`,
      "hub.callback": "https://${process.env.TWITCH_DOMAIN}/twitch_subscription",
      "hub.lease_seconds": "864000",
      "hub.secret": process.env.TWITCH_SECRET
    headers: {
      'Content-Type': 'application/json',
      'Client-ID': process.env.TWITCH_CLIENT_ID
  }).then(resp => console.log(resp.status))

And then on receiving a webhook we check if it’s a go live event:

    console.log('GOT POST at Twitch Sub');
    const data =;
    if (data.length == 0) {
      return h.response().code(202);
    const payload = data[0];
    if (payload.type == "live") {
      console.log('Body is: ', payload);
      const title = payload.title;
      const thumnail = "";
      const gameId = payload.game_id;
      postToDiscord(title, thumnail, gameId).then(() => console.log('Should Have Posted to Discord')).catch((err) => console.log(err));
    return h.response().code(202);

However we seem to be getting go live events whenever they change their game. This is happening to us for multiple sources. Whether we update the game through twitch itself, or through moobot. This is causing many events to be sent to our discord pinging everyone. This feels like a bug since the event type is “live”. If this is not a bug, how should we detect if this is a game change, or a new go live?

As specified in their announcement Stream Webhook Update the webhook is now a stream change webhook, not specifically a stream up/down webhook any more. It is not a bug, (although this webhook has been particularly buggy since the change for other reasons, the fact that you’re getting notifications on a game change is NOT a bug and is intended).

The easiest way to know if a notification is for a stream going live, or just a change of one of the stream properties, is to store the previous stream state so that you can compare that with the new notification and determine the change.

Ah Thanks, I missed this update message. I’ll work on reworking our notifier. Thanks.

As a side note, there is a parameter called: “type” here. It’d be really amazing if we actually used the type to say: “live” vs. “game_change” or something. I’m not sure how much work that is from your perspective, and it may be way too crazy. But it would be nice to be able to distinguish using the type field.

Webhook data is based on the underlying API, in this case the Get Streams endpoint. Because of this the type field, along with all other fields, will always be what the API would return. Having the field include the type of change that triggered a webhook notification would only have use within the context of webhooks, to anyone just querying the API having a field that says game_change would make little sense.

It may be possible for notification trigger reason to be added outside of the body data, perhaps in the headers just as the Twitch notification ID and timestamp are there, but that depends on what is allowed within the webhook specification, and is an idea for the webhooks team to think about.

When I receive a webhook, I fetch the last webhook from storage.

And compare the two.

Then depending on my criteria I choose to notify or not.

In your case, you just need to compare the old data to the new data and see if it’s changed from blank (or empty array) to a payload of data. This also means if someone wants to get the current stream title/game/uptime in discord I don’t need to do a API request as I have it in storage.

In this case I use Redis for storage.

Basically this is identical to using long poll, so if I switched from webhooks to long poll, I wouldn’t need to change the handler, just the fetch/data source method(s).

The only reason I mention this, is under your current method, you are renotifiying Discord when a stream dumps and restarts (dropped connection, OBS Crash etc). So you need this “fix” in your system anyway.

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