Access token refresh resets the subscription to webhooks?

The “access_token” refresh resets the subscription to webhooks?
I came to this conclusion while I was testing the “channel subscriptions” webhook, and the only thing that changed a few hours after the subscription request was the “access_token” (Updated using the “refresh_token”).
I set the duration to 3 days, as below (I masked sensitive data with ‘X’):

curl -H 'Content-Type: application/json' -H 'Client-ID: l94wqf6XXXX7ltimejpsoxXXXXXX' -H 'Authorization: Bearer 7mXXXXXp7mXXXXXXXc8x3bzh' -X POST -d '{"hub.callback": "", "hub.mode": "subscribe", "hub.topic": "", "hub.lease_seconds": 259200}' ''

At the beginning all notifications are delivered, in fact I have a log with all requests made by to my endpoint.
A few hours later, reached the next live (~ 8h later), they no longer arrive.

So, as I said at the beginning, is it possible that the change of the access token ends the subscriptions to the webhooks?

Webhooks will use

  • the time you specify


  • the access token used to create the subscription has less time left than what you asked for

So, if you use a token with an hour left on it
And ask for 10 days
You get an hour.

TLDR: Webhooks use what you ask for, unless, the token has less time left than you asked for

A user access token last for four hours.
So if you ask for 10 days, you’ll get four hours (or what is left on the token)

So you have to resubscribe to the subscriptions webhook every four hours. (after of course refreshing the token)

When you create the subscription to the topic, the API will return the actual time/lease_seconds that is used, and you can use the active webhooks endpoint to check

Excuse me, so it is “simply” not possible to have a subscription to the “channel subscribers” webhook for more than four hours…


You make the subscription using token foo
When token foo expires, the subscription dies with it.

So you have to remake the subscription every 3 1/2 hours (or so) as apposed to every 10 days.

EventSub solves this issue (as it uses app access tokens and does the security check another way), but as discussed in our other thread, lacks the subscription notification data we need.