09-26-2024 12:30
09-26-2024 12:30
We have some cases where a user might re-authenticate fitbit on a different user account in our system. In those cases we get a conflict but that's not very helpful for the user because all we can say is that there's another user with this fitbit again rather than unsubscribing the old account and linking this one.
I tried using the subscription info passed back to unsubscribe but it looks like that's no possible. I keep getting a 404 which I assume is because a logged in user can't unsub another user with their access token.
I also looked around to see if there's a way to use the client id + secret to make changes to the subscription but that also didn't work. I could never get the auth to work. It kept complaining the client_id was wrong.
So how do we best handle subscription conflicts such that we can unsub the existing user first?
Is there that an easy way to unsub the user?
It also makes me wonder, what happens if (for whatever reason), you lose the refresh key... does that mean you've essentially lost access to the user? I would have expected a fallback method using client id + secret to because to access data or at the very least get new tokens through the server side without needing a challenge code or web flow.
Any help would be appreciated.
Thanks
09-30-2024 12:24
09-30-2024 12:24
Hi @mxsfvr
The only reason you would get a conflict when creating the subscription is
Since you said the user is authenticating using a different user account, then scenario 2 is what you are hitting. How are you generating the subscription ID such that the same subscription ID is being generated for 2 users?
09-30-2024 13:23
09-30-2024 13:23
Hi Gordon,
The subscription name is based on our internal IDs which is the main reason we're seeing the issue. I.e