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.

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.

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.

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.

Did this answer your question?