Web API Q's

[alexandrag2254]

I have been reading up on the fitbit api and have a few questions below. Thank you in advance!

1. Can a client — that has been set up with a fitbit dev account — access multiple user devices and their respective data— For example, I have multiple family members, who would like me to organize and keep track of their fitbit data info for them. 

2. If above is possible, what info do I need to request from my family members to have appropriate authorization to fetch the fitbit activity data? i.e. specific keys/IDs from their user account and/or wearable device?

3. In order to set up a subscription api, do we need to have different authorization from the user in addition to the authorization required for basic api calls?

4. Currently, is there a way to limit access to a certain devices's data on the basis of time. For example, I grant this source to have access to my activity data for the next 48hrs only. I know there is a expiration date for a dev auth token but is this the same?

5. As I practice using the fitbit api, is there a testing environment or dummy device data I can work with?

Thank you again!

~Alexandra

[jmitchell38488]

1. Yes, this is possible, but you will need to 'authorize' the family members application through the open authentication protocol (oauth).

2. You can view the docs here: https://dev.fitbit.com/docs/oauth2/ but you can also use @DanCFitbit's library on GitHub, or my library on GitHub to handle the authentication and authorization steps. They are simplified with instructions included.

3. Subscriptions are push events from Fitbit, so once a user is authorized on your application, and your subscription endpoint is authorized (you need to do this separately), push events will be sent to your subscription endpoint. It's really just a notification of sorts and you still need to go to the FitBit API to get the latest data.

4. You can if you use the implicit mode you can specific time to expire the access code

5. For oauth1 you can set it up on any local environment without a valid URL, or you can use what's available on the dev.fitbit.com portal. Otherwise for oauth2, you need to have a valid url to work with, that fitbit can access. It's one of the caveats of oauth2.

[alexandrag2254]

thank you @jmitchell38488!

follow up questions: 

1. Is there a robust testing fibit dataset I can practice with?

2. Clarification: consumer key and consumer secret are to authorize a web application. 

Once a user signs in to Fitbit through my web app, I will get back a unique access token and access token secret that corresponds with that particular user ( so these tokens can be stored in a local database for later api calls ) Is this correct? 

3. If I am using Authorization mode instead of implicit, is there a way the user can limit the use of refresh tokens?

[jmitchell38488 · Accepted solution]

Sorry for the late reply, busy weekend!

1. Unfortunately not, you will need 1 fitbit device with data on it. If you search the forums you will see posts from @JeremiahFitbit where he's discussed authorizing his fitbit device on your application in read-only mode, but it's not the same as a data sandbox environment.

2. You use the consumer key and consumer secret to form part of the authorization header. The API returns an access token, refresh token and expires date for the access token. You use the access token for each request to the API. After 1 hour the token will automatically expire, regardless how many times you use it, so you will need to use the refresh token to fetch a new access token.

3. No, you can view my profile for a recent forum thread that discusses when refresh tokens become invalid a user has to re-authorize their account on your application. They can de-authorize their account on your application and any subsequent requests will need you to re-authorize them. Something that isn't really covered but is extremely important; there is only ever 1 refresh token in existence for an account <=> application relationship. So if you create an application A and user 1 authorizes themselves on your application, then that relationship exists. If that user authorizes themselves again as a new user in your system, but uses the same fitbit account credentials, the old authorization will become invalidated.

[rthille]

"If that user authorizes themselves again as a new user in your system, but uses the same fitbit account credentials, the old authorization will become invalidated."

That bit is critical.  We've got an app and we'd love to be able to demo it with "real" data for Fitbit, but that involves not being able to have the Fitbit account connected to our personal account as well as the demo account.  

If Fitbit had a sandbox account that had "real" (algorithmically generated or not, but somewhat real looking) data that Web API developers could connect to their apps (hopefully multiple times, or maybe a few copies of the account with same/different data) for testing and demos, that would be awesome.