You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a client with both an AppAccessToken and a UserAccessToken, the client favors the UserAccessToken over the AppAccessToken. However, certain Helix API calls require the use of an AppAccessToken, i.e. CreateEventSubSubscription.
The client should automatically use the AppAccessToken field for calls that require AppAccessToken, or otherwise allow AppAccessToken to be passed in per call as in #128.
The text was updated successfully, but these errors were encountered:
Had this issue before as well. From experience it's best and maybe even recommended? To Set the UserAccessToken before you do that request and then clear it again after.
Maybe that's done intentionally since UserAccessTokens and has to be switch for each user anyway, but then It should just be an argument in the function IMO
What I ended up doing as a work around is instantiating a second client just for calls that need an AppAccessToken and making sure to never set a UserAccessToken on it. I really want to avoid mutating state where possible in order to reduce possible bugs during concurrency.
When creating a client with both an
AppAccessToken
and aUserAccessToken
, the client favors theUserAccessToken
over theAppAccessToken
. However, certain Helix API calls require the use of anAppAccessToken
, i.e.CreateEventSubSubscription
.The client should automatically use the AppAccessToken field for calls that require AppAccessToken, or otherwise allow AppAccessToken to be passed in per call as in #128.
The text was updated successfully, but these errors were encountered: