Problems with integrations

[WalkfitDEV]

Dear Fitbit Team,

I have a few technical questions we hope you can assist us with.

1. Deleting subscriptions for users we do not have data anymore. In some cases we receive hook subscription data for users that do not have any data for access\refresh token in our database, or a token is lost on our end. Without this we are unable to DELETE subscriptions for these users. We cannot ask users to refresh data as in some cases they are not using our application anymore. How can we stop receiving subscriptions for such users when we do not have any data for them anymore?
2. It is possible to observe the difference between what users see in the Fitbit app and what we’re getting from Fitbit API. Data will not match even after a couple of hours. What might be the reason for such behavior? 
3. Some users set up activity subscription hooks, but we do not get any data updates. We received a couple of complaints about this to our customer service, but it seems that on our end flow was created in the correct way.  Subscription is available when calling the Fitbit API and it is showing the same id as we have in our db, but we do not get any hooks updates.
4. Sometimes we receive hooks to update the same user multiple times in a short timespan (like 10000+ hook calls in 5min). Example for single user (time in UTC).It is not a one time incident, it has already happened a couple of times. Could you please explain why this is happening?
   
5. In some cases we receive hook data really often and this can exhaust the rate limit for the user. The rate limit is 150 API requests per hour and we need to pull data for distance and steps. So every hook call consumes 2 “tokens” for rate limit. It happens that in 1h we get more than 75 hook calls. What can we do to improve or maybe there is a way to reduce how often hooks are called? 
   
6. Please update this page: https://dev.fitbit.com/build/reference/web-api/partner-help/ Mail listed there to contact unfortunately does not exist anymore.

We appreciate your time and assistance in addressing these technical questions. Your insights will be invaluable as we proceed with our integration efforts. If you need any details, please contact me and I will be happy to provide even more information.

Thank you for your support.

[GordonFitbit]

Hi @WalkfitDEV 

Some of the problems you reported were suppose to be fixed earlier this year.  So, I'll need to do some investigation to figure out what is going on.  Regarding question #6, that support page you referenced is outdated and was removed over 5 years ago.  You should have been redirected you to our current support page.  So, I'll fix the redirect.

[WalkfitDEV]

Hi! Thanks for help!

We have seen some improvement for point nr 4 last month, thank you for that!
Unfortunately issue nr 3 is still existing, and we still get complains about it.

We also want to remove communication for inactive users and we do not know what to do in case of scenario described in point 1, so it would be amazing to get your advice there. 

[DonDickinson]

Per #3, I have had success directing the user to: https://www.fitbit.com/settings/applications

And then having them revoke access and reconnect via OAuth to our app. I know it's just a work-around, but it *usually* fixes the problem.

[WalkfitDEV]

@GordonFitbit Hi! Any updates? It is 10 days from when I posted it 😞 

[GordonFitbit]

Hi @WalkfitDEV 

Thank you for your patience.

1. What we can do in this case is help you recover the last refresh token for this user so you can call the revoke token endpoint.  This should stop your application from receiving future webhook notifications.  Please create a support ticket in Issue Tracker requesting help and provide your client ID and the impacting user IDs.  In the future, there are several things you can do to stop this from occurring:

• Add userRevokedAccess collection to your subscriptions.  If a user revokes consent, then you can clean up things on your end.  For more information, see Creating a subscription.
• If you have a mechanism to know when a user stopped using your app, but they have not revoked consent, you application can call the revoke token endpoint before deleting their tokens.  For more information, see Revoke Token.

2. We don't have a method to allow 3P developers to see the user's data in the Fitbit app.  There could be various reasons for this.  Please create a new ticket in Issue Tracker so we can get some information from you to investigate and provide the user ID, the endpoint you are calling, the endpoint response, pictures of mobile app on the same day that show the different data.  

3. There could be various reasons for not receiving webhooks (i.e. the user changed userId, the user changed scopes they are consenting to share, your subscriber being down, the user is not syncing their device, bad devices, etc.).   Please create a new ticket in Issue Tracker so we can get some information from you to investigate and provide your client ID and the user ID.

4. The times that I have seen this, there is a problem between the mobile app and Fitbit device where they get stuck in a syncing loop.   On rare occasions, another 3rd party application that they share data with is has a bug where they are constantly pushing data to Fitbit, which in turn sends you a webhook.   Please create a new ticket in Issue Tracker so we can get some information from you to investigate and provide your client ID and the user ID.

5. The token endpoints have a different rate limit, so they should not impact your standard 150 API calls per hour rate limit.  We can investigate this issue with #4.

6. https://dev.fitbit.com/build/reference/web-api/partner-help/ is an old page and should not be expose.  The current help page is https://dev.fitbit.com/build/reference/web-api/help/.   I will remove the old page.