EventSub creation returning 410 "gone" status

API
1

Having a hard time figuring out why this is returning 410 "gone" from the API.

      const res = await fetch(
        'https://api.twitch.tv/helix/eventsub/subscriptions',
        {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
            'Client-ID': CONFIG.get().twitch.apiClientId,
            Authorization: `Bearer ${CONFIG.get().twitch.apiOwnerOauthToken}`
          },
          body: JSON.stringify({
            type: 'channel.follow',
            version: '1',
            condition: {
              broadcaster_user_id: CONFIG.get().twitch.ownerId
            },
            transport: {
              method: 'websocket',
              session_id: event.payload.session.id
            }
          })
        }
      );

I’ve tested purposely including a bad access token to make sure it returns unauthorized as well as malforming the request to make sure it’s returning bad request, but when everything is seemingly working properly, I’m getting gone.

This is being sent well before the 10 seconds required and logs show that it returns gone before my websocket connection is closed with reason: connection unused.

I’ve also tested the webhook transport and get the same gone status. Is there a new endpoint that I’m not seeing in the docs or something else I’m missing?

2

Follows version 1 is dead!

Please use follows version 2!

it comes with an additional condition and different authentication requirements

3

Thanks @BarryCarlyon –

Do you know if this is also available for the websocket transport, because the updated is giving me a Bad Request:

          body: JSON.stringify({
            type: 'channel.follow',
            version: '2',
            condition: {
              broadcaster_user_id: CONFIG.get().twitch.ownerId,
              moderator_user_id: CONFIG.get().twitch.ownerId
            },
            transport: {
              method: 'websocket',
              session_id: event.payload.session.id
            }
          })
4

Yes it’s transport agnostic.

Whats the body message of the response. It should describe the fault/issue.

The HTTP Code is half the information

You did reauthenticate with the new/additional scope as well?

5

Thanks @BarryCarlyon – The problem ended up being sending the ID’s over as integers and not strings (which I found from another one of your answers.) Really appreciate your quick responses.

6

Glad it was a simple one and most welcome!

And yes userID’s are strings (that currently look numeric)

7

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