How can I increase the lifetime of a user access token?

Hi there :slight_smile:

I used the Twitch CLI to generate a user access token, and after the call I see that the token expires in three hours after the generation.
It is way to short for me, is there anything that we can do to increase the lifetime of the token ?

I saw that there is a refresh token so maybe I can deal that problem with this token, but I really don’t know how it works.
Since I will be on my stream when I will use my application, I don’t want to pause what I do in my stream and refresh the token with the CLI and then go back to my stream, you know.

Thank you very much for your help ! :slight_smile:

No. Regualr user tokens live for 4 hours

Thats the “correct” work flow.

You use the refresh token to get a new access token.

Cli is handy for testing with.

But for your “true” application you would seed you application with a user and refresh token
And it will handle refreshing on it’s own

It might be more suitable to use an implicit token for your application which is good for 60 days and just give your application a new token each time you start your stream.

And depending on what data you are consuming or using you might not need to refresh. (EventSub websockets will live beyond the death of the token for example)

1 Like

So for example, in JavaScript, I will just need to make an axios (or ajax) request with the refresh token to get my user access token still available for 4 hours more ?

For my application, I will need to read and send chat messages.
And also I would like to listen to Events on my stream (user follow, subscriptions, raid, etc). This part is managed by the Websocket connexion right ?

Oh great so I don’t need to refresh the token for the Websocket ? I just need to put all the informations that I need and then event if the token expires, the websocket will still work ? But if I restart my application and my Websocket connexion, I will have to get a non expired token right ?

Correct, I tend to periodically (like 15 minutes) check the token’s expirartion left using the validation endpoint and if it’s got less than 30 minutes left on it refresh it then

This will return a new access and refresh token.

To read/write chat the token only needs to be valid when the “bot”/script starts.
When the token expires the bot/script is not disconnected from chat, so no refresh needed

Yeah, and again, the token only needs to be valid when you create the subscriptions, so no refresh needed

Correct. The subscriptions will stay alive until you F5 page/restart the application.


Ok right I get it !

I’m sorry but in this page, I don’t see any mention of a user follow in the list of event that I can trigger with the twitch CLI. Maybe I don’t look correctly ?

Thanks again for your awesome help :slight_smile:

The documentation lacks behind “live” I don’t know if the new follows eventsub is in the CLI yet.

and it doesn’t test EventSub Websockets anyway

Oh right… so how can I send a “New follower” notification to my stream for testing purposes ?

Over the EventSub Websocket? You can’t
Over the EventSub Webhook the old topic is twitch event trigger follow the new/in beta topic has a similar payload.

So what is the best option ? I wanted the same functionnalities as the Streamlabs Dashboard (notifications when follow, sub, raid, host, etc.).
What I wanted is to get a JSON response with all the information about the notification each time that there is an event on my stream, and then handle the rest to display it on my stream with JS/HTML/CSS.

So for that I can’t use the Websocket connexion because you said earlier that this one can’t handle follow events.

So which option could fit my requirement ?

Thank you for your time :slight_smile:

Thats not what I said.

I said you cannot test EventSub websockets at all.
The CLI can be used to send test payloads to EventSub Webhooks.
But at time of writing the EventSub Websocket has no testing mechanism.

You’d have to connect up and wait for live data to occur.
But the EventSub is “transport agnostic” so the data send to either transport has the same format.

Well hosts are no more.

But everything in this list is available over EventSub (either transport) and for your use case sounds like EventSub WebSockets is the best solution.

1 Like

Oh… Ok I’m sorry for that misunderstanding.

So if I get it, for my case, it’s better to use Webhook for testing purposes (when i use my application localy) and the Websocket for production use (when I use my application on my stream). Is that correct ?
And for testing when a user has follow my channel, I can use the Webhook right ?

Okay thank you very much for that :slight_smile:

A webhook will require a publically accessable URL.

So if you are going the webhook route then I’d just webhooks for the whole thing.

Otherwise build your tool off the documented payloads and wait for live data to occur, no need to “test”

1 Like

Ok right, I think I will do that, it’s true that the documented payloads are well… documented :stuck_out_tongue:

So I will go with that, thanks again for your awesome help ! :slight_smile:

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