Our API expires
access_tokens 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.
refresh_token should be stored against your user record to ensure you can maintain access to the user's calendar data.
If a token has expired then our API will respond with a
401 status code. It's at this point you will need to refresh the token to continue to interact with the user's calendar data.
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.