Questions about the new API app access token support update

API
1

The latest update to the Twitch API (2026‑02‑27) has enabled App Access Token support for various endpoints. I have been unable to find a press release or other information on this change and what it means for the Helix API going forward. My questions are as follows:

  1. Is this change indicative of a shift away from User Access Token usage entirely, where user authorization state is managed by Twitch itself (i.e., no refresh flow), or is it simply being made as an alternative?
  2. Does the user’s authorization have to be tied to a currently valid (non-expired) User Access Token, or does the authorization simply have to be non-revoked? In other words, do we have to keep refreshing the underlying User Access Token in order to use the App Access Token to make the request?
  3. Are there any plans for depreciation of User Access Tokens, no matter how far out?
  4. Are there plans to include all current User Access Token-based Helix endpoints, or are there specific endpoints that will always remain only User Access Token authenticated?
  5. Are there plans for an Authentication API endpoint that identifies the scopes a user has authorized to a specific Client Id?
  6. What is the motivation behind this change? The only endpoints that previously had this behavior were related to EventSub subscriptions (specifically those using the Webhook or Conduit transport), of which I am also curious as to the motivation behind using an App Access Token with a prior user authorization.
2

Is this change indicative of a shift away from User Access Token usage entirely, where user authorization state is managed by Twitch itself (i.e., no refresh flow), or is it simply being made as an alternative?

This is simply expanding the capabilities of App tokens, so that for server-side apps there’s less need to juggle multiple OAuth tokens as many use cases can now be solved by just using the single App token and not need to store/refresh user tokens at all after a user auths with the appropriate permissions.

Does the user’s authorization have to be tied to a currently valid (non-expired) User Access Token, or does the authorization simply have to be non-revoked? In other words, do we have to keep refreshing the underlying User Access Token in order to use the App Access Token to make the request?

It doesn’t matter of the User token expires. As long as the user doesn’t disconnect from the app you’ll be able to use the App token on the the supported endpoints providing the user has granted the scopes needed. If you need more scopes the user will have to auth again with more scopes.

To expand on this as well, the App will have the sum total of all the scopes a user has granted. So if a user goes through OAuth granting your app bits:read, and then a separate time goes through OAuth for the same client ID but with only channel:manage:broadcast, then the app will have both bits:read and channel:manage:broadcast permissions from that user.,

Are there any plans for depreciation of User Access Tokens, no matter how far out?

Nope. User tokens are still have their use cases where App tokens aren’t viable, such as client-side apps. As such there’s no current plans to deprecate them.

Are there plans to include all current User Access Token-based Helix endpoints, or are there specific endpoints that will always remain only User Access Token authenticated?

Keep in mind, as it shows on the Docs this is still a beta rollout of more endpoints supporting App tokens. It’s possible more will support App tokens in the future, but it’s also possible that it just may not be viable for some. Nothing official has been announced as to what may be on the roadmap for further endpoint support.

Are there plans for an Authentication API endpoint that identifies the scopes a user has authorized to a specific Client Id?

Get Authorization by User already allows you to do just that

What is the motivation behind this change? The only endpoints that previously had this behavior were related to EventSub subscriptions (specifically those using the Webhook or Conduit transport), of which I am also curious as to the motivation behind using an App Access Token with a prior user authorization

After some endpoints showed that this sort of functionality for App tokens was possible, it became a feature that many developers requested for the reasons I’ve previously mentioned such as reducing the need for storing/refreshing user tokens, simplification of code, potentially reduction in costs (such as if an app used to need an database just to maintain User Tokens, it might now be able to ditch needing a DB entirely, or scale down).

3

Send chat message launched with the ability to use App Access Tokens.

EventSub on the webhooks/conduits transport requires App Access Tokens, where as pure websockets are user tokens.

Now that more endpoints support using an app access token, conceptually a chat bot can auth the user(s) needed but for all operations that a chatbot does, reading/writing chat, doing moderating actions, etc it only ever needs the App Access Token.

Until this batch of endpoints (notably ban/unban a user), a bot would have to context/token switch between sending chat with app access token, and doing a ban with a different token.

And concepually, in my opinion, operating an app access token is easier, as when/if the app access token expires you just new one wiht the clientID/secret (from env) rather than loading a refresh token as well from a database.

So it makes chat bots easier to build and operate, in my opinion.

4

Guys, thank you so much for the detailed responses. All of this is really helpful. Somehow I had totally forgotten about Get Authorization By User and the other App Access Token optional endpoints, so my apologies.