Cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Resolving subscription conflicts

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

Best Answer
0 Votes
2 REPLIES 2

Hi @mxsfvr 

The only reason you would get a conflict when creating the subscription is 

  1. if the given user is already subscribed to this stream using a different subscription ID
  2. if the given subscription ID is already used to identify a subscription to a different stream

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?

Gordon Crenshaw
Senior Technical Solutions Consultant
Fitbit Partner Engineering & Web API Support | Google
Best Answer
0 Votes

Hi Gordon,

The subscription name is based on our internal IDs which is the main reason we're seeing the issue. I.e 

1/user/-/activities/apiSubscriptions/{scope}_{userId}.json.
 
So if a user creates a subscription with account 1 (sub id: activity_1), and then creates a new account 2 and tries to subscribe (sub id:  activity_2), it'll conflict based on the pattern above. Ideally, I'd like to be able to unsub the old one and resub the new account. So I'm looking for guidance on how to do the unsub in the moment I get the conflict. I'm open to other architecture options as well but in the short term I'm looking to put in a simpler resolution.
 
Thanks
Best Answer
0 Votes