Why do access_tokens expire and how can you refresh them?

Our API expires the access_token in order to reduce the risk of your users’ calendar data being compromised. When you obtain authorization to access a user’s calendar, a refresh_token will be issued alongside the access_token to allow your application to obtain a new access_token without user involvement.

Both the access_token and refresh_token should be stored against your user record to ensure you can maintain access to the user’s calendar data.

To determine when a token has expired, our API will respond with a 401 status code when making an api request or you can track it using the expires_in parameter located in the response body when requesting an access_token. It’s at this point where you will need to refresh the token to continue to interact with the user’s calendar data.

The new access_token and the refresh_token should be updated in your user record. The refresh_token is permanent until is used, however it may change at this point.

All of our SDKs provide a method for doing this or see Refreshing an Access Token in our API docs. This process is also described in the OAuth2 spec

Whilst in development mode we expire the token quite quickly, a few hours or so, to ensure that this is being handled properly before your app gets into production. We did have some situations where customers integrated so quickly that they hadn’t dealt with this before going live and thus caused production 🔥 when calendar access was expired. Never pleasant to deal with.

After a period we then push this out to a longer time frame to better balance the necessity to refresh.