02-15-2021 09:13
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

02-15-2021 09:13
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hi all! Is there are an option to get field expires (like timestamp) instead of (or with) expires_in - to get token from Fitbit? If yes, would you please describe how to use expired field?
Some background
Our solution - client-server. Token uses expires_in value (as it is said in Fitbit documentation - link). Although our API (backend) requests us to use expires value for the token. Documentation or how-to work with expires (instead of expires_in) for the token in Fitbit we couldn't find. Any help would be highly appreciated.
Answered! Go to the Best Answer.
Accepted Solutions
02-17-2021 16:06 - edited 02-17-2021 16:19
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



02-17-2021 16:06 - edited 02-17-2021 16:19
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hi @AlexeyGarmatin,
Welcome to the forums!
Unfortunately, there isn't a parameter for timestamp that can be used in the authorization URL. For a list of parameters you can use, please check our documentation here: https://dev.fitbit.com/build/reference/web-api/oauth2#authorization-page
If you're using the Implicit Grant flow, the "expires_in" parameter is what the user will see when they are selecting scopes of what data to share on the authorization page. For example, if you set your authorization URL to include "expires_in=31536000", the authorization page will indicate consent will be allowed for 1 year. However, the Fitbit user will ultimately have the final say in how long to share access for as they will have the option to change the duration to 1 day, 1 week, or 30 days. When the user consents, you'll receive an access token from the user, that when parsed, will provide you with the following information:
{
"access_token": "<access_token>",
"expires_in": 86400,
"refresh_token": "<refresh_token>",
"token_type": "Bearer",
"user_id": "ABC123"
}
In the response, the expires_in value will indicate how long the user wants to share their data.
Depending on your architecture, the user will need to provide consent again when their token expires (Implicit Grant Flow) or your application will need to use the refresh token to obtain a new access token/refresh token pair for the Fitbit user without asking them to go through the authorization process again (Authorization Code Grant Flow).
I hope this helps. Let me know if you have additional questions.

02-17-2021 16:06 - edited 02-17-2021 16:19
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post



02-17-2021 16:06 - edited 02-17-2021 16:19
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hi @AlexeyGarmatin,
Welcome to the forums!
Unfortunately, there isn't a parameter for timestamp that can be used in the authorization URL. For a list of parameters you can use, please check our documentation here: https://dev.fitbit.com/build/reference/web-api/oauth2#authorization-page
If you're using the Implicit Grant flow, the "expires_in" parameter is what the user will see when they are selecting scopes of what data to share on the authorization page. For example, if you set your authorization URL to include "expires_in=31536000", the authorization page will indicate consent will be allowed for 1 year. However, the Fitbit user will ultimately have the final say in how long to share access for as they will have the option to change the duration to 1 day, 1 week, or 30 days. When the user consents, you'll receive an access token from the user, that when parsed, will provide you with the following information:
{
"access_token": "<access_token>",
"expires_in": 86400,
"refresh_token": "<refresh_token>",
"token_type": "Bearer",
"user_id": "ABC123"
}
In the response, the expires_in value will indicate how long the user wants to share their data.
Depending on your architecture, the user will need to provide consent again when their token expires (Implicit Grant Flow) or your application will need to use the refresh token to obtain a new access token/refresh token pair for the Fitbit user without asking them to go through the authorization process again (Authorization Code Grant Flow).
I hope this helps. Let me know if you have additional questions.

02-19-2021 06:44
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post

02-19-2021 06:44
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Report this post
Hi @JohnFitbit
Thank you for your comment! And examples/details. Appreciate it 🤝

