Problem with EventSub via webhook and getting authorization

API
1

Running into a problem here and any help would be greatly appreciated. Thank you in advance!

I am currently trying to subscribe to eventsub channel.chat.message for a webhook. When doing so with my app access token I get the “subscription missing proper authorization” error message back.

    $url = "https://api.twitch.tv/helix/eventsub/subscriptions";
        
    $curl = curl_init($url);
    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

    $data = array(
        "type" => "channel.chat.message",
        "version" => "1",
        "condition" => array (
            "broadcaster_user_id" => "redacted",
            "user_id" => "redacted"
        ),
        "transport" => array (
            "method" => "webhook",
            "callback" => "redacted",
            "secret" => $eventsub_secret
        )
    );

    curl_setopt($curl, CURLOPT_POSTFIELDS, json_encode($data));

    $headers = array(
       "Content-Type: application/json",
       "Authorization: Bearer ".$oauth_app_access_token,
       "Client-Id: ".$clientid,
    );
    curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
    //for debug only!
    curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, false);
    curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
    
    $resp = curl_exec($curl);
    $info = curl_getinfo($curl);
    curl_close($curl);
    
     echo '<pre>Results:
         '; print_r($resp); echo '</pre>';
     echo '<pre>Curl Info:
         '; print_r($info); echo '</pre>';

I am trying to do this for my channel with a bot that I have created in my developer console under applications. The bot is setup to moderate my channel so based on the documentation I just need the app access token and the user access token. I believe the user access token has the correct scope which is “scope”:[“user:bot”,“user:read:chat”,“user:write:chat”] as returned by my request with the “code” to https://id.twitch.tv/oauth2/token.

I am confused by the documentation which says:

“The first User Access Token you’ll need is one for the bot that will be reading chat”

How can I do this “for the bot”? When I go through the “Authorization code grant flow” the authorization comes from my account, so I am confused. What am I missing here?

2

I have updated my “Authorization code grant flow” to request every single permission available but I am still getting the same “subscription missing proper authorization” error message. Thoughts?

3

For channel.chat.message over webhook

Requires scopes as follows

  • from user_id user:read:chat and user:bot

and either

  • user_id is a moderator of broadcaster_user_id
  • channel:bot from broadcaster_user_id

After getting user tokens from the user_id and the broadcaster_user_id generate a seperate client credentials token to create subscriptions with

As you redacted the userID’s I cannot do any checks for if the user_id is a moderator for broadcaster_user_id

Correct, generate the user token with the needed scopes then basically ignore it and generated a Client Credentials token.

You go thru the oAuth flow as your bot.
Sounds like you did the oAuth flow as you instead of your bot and your user token with user:botetc on is no for your bot account.

So you need to generate a user token for your bot account.

IE in your browser you need to be logged into Twitch as the bot account, when I need to auth a bot I tend to open Chrome in incognito for that.

So here on the left I am Authing as barrycarlyon in chrome and on the right I am authing as barrycarlyonbot in Firefox.

image
image2502×846 146 KB

Reference docs:

4

Thank you for responding. The bot is created as an application under my main account. How do you actually log in as that bot or is that the problem and I need to create a totally new account and use that as the bot?

5

No this is a ClientID created with a name foo that is created under your account.

A client ID is just credentials to access the API and/or create oAuth/access tokens for other accounts

So all you seem to have done is create a clientID. And not the user account needed for your bot.

All Twitch Bots are regular user accounts, with usernames, passwords and 2fa’s.

Those user account have granted access to a ClientID on behalf of the user creating a link between the user and the clientID

Allowing the code behind the ClientID to run as a bot under the user account in question

Here the broadcaster_user_id would of been you and the user_id your bot

If the user account doesn’t exist whom did you do /mod to?

6

The bot has a name SoulManBot in the application definition and has its own user ID which can be queried as usual.

7

So you need to login to Twitch as SoulManBot then do an oAuth flow to your ClientID as SoulManBot

The name (and owner) of the application ClientID is irrelevant

As you’ll grant access between SoulManBot and your ClientID which generates permissions.

Then you use permissions to send to chat as the authenticated user which will be SoulManBot in this case. (Not whatever your ClientID is called, it just happens to have the same name)

8

I was able to make it work with a totally separate twitch account. I will try a little bit longer to see if I can make this other application work that is in my account but at a minimum I can use this other account as the bot if I cannot make this work in the single account. Thank you for the help.

9

Not sure what do you mean?

Assuming you own/control SoulManBot just auth SoulManBot aginst your ClientID.

The owner of the ClientID doesn’t matter

10

That is the thing. Maybe I actually don’t own that account and I just happened to create the app with the same and confused the process.

11

Ah you were thinking Twitch Client ID’s work similar to Discord.

Discords different and one of the few oAuth flows that give you a bot account with the ClientID

12

The solution if you are using the same account for your channel and the bot is to use the same user_id as the subscriber and the broadcaster. I assume this means though when my application sends a message to my channel it would actually come from me SoulMan vs the name of the application SoulManBot. Which is technically not what I want but I have to figure out what to name the actual Bot account in this instance as it isnt what I expected at this point and what I want to use is taken :smiley:

13

as you noted and for clarity of others finding this post:

When you send a message via the API it sends the message as the authenticating user, ie the user described as sender_id in the payload and the oAuth token used to call this API.

As otherwise anyone generating an implict oAuth token can send messages as the application which is obviously not a good idea.

Essentially chatbots login to chat to send messages the same as a normal user would or if you were using a third party chat client, you login as the user you want to send chat messages as, and that user needs to exist as a normal user, that you also control (aka an alt account of yourself), and that user needs to have granted permissions to your application/ClientID.

The name of the application/ClientID is only used on oAuth dialogs presented to users and on the settings/connections page of the Twitch Frontend.

So the name of the ClientID and whom owns the ClientID is irrelevant when it comes to sending/recieving chat messages. Like you could go to my TwitchDev GitHub examples, lift the ClientID from it (since ClientID’s are public) generate implicit oAuth tokens and send messages to chat, (I even have a unpublished exmaple where you could run a chatbot from the Github pages deploy of that Examples repo, you just have to login the bot account via oAuth, then you have a chatbot running from my clientID with your user account)

Note: This differs from Discord as Discord gives you a user to go with your Application (if requesting bot stuff with a Discord ClientID), and Discord will give you the token (aka password) to use to connect to the Discord services for the purpose of running your bot.

14

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