Subscription API down?

[PawelRTE]

Hello,

Our previously working code is now breaking during creation of subscriptions with valid oauth session. Is this issue related to the device sync issue announced about an hour ago? fitbitstatus.com shows all green at this moment.

Thank you,

Pawel

[PawelRTE · Accepted solution]

Turns out that subscription API is a touchy beast:

OAuth2 error returned includes status of 409. Per documentation here (https://dev.fitbit.com/build/reference/web-api/subscriptions/), 409 is results when a user tries to 2 subscriptions to the same resource:

A single user can only subscribe to the same stream once. If a conflict arises trying to add a subscription, the server will respond with an HTTP 409 Conflict. It will still return the same response elements, but in this case, the body will tell you that the subscription already exists so that corrective action must be taken.

In our case, we weren't able to a) create subscriptions b) delete subscriptions.

Subscriptions deletion started working when the scope included: 

activity nutrition profile settings sleep weight

and the user account allowed access to all of them.

The above worked also for subscription creation, though I suspect, settings is related to subscription creation and could be limited to that. But what's a subscription creation without deletion?

It would indeed be very helpful for the app to verify appropriate scope grant upon FitbitAPI doing a callback so that application could instruct user when scopes granted during login differ from scope expected by the app. Yes, one could verify the scopes by listing subscriptions (https://dev.fitbit.com/build/reference/web-api/subscriptions/#getting-a-list-of-subscriptions), but that seems inefficient.

--p

[GordonFitbit]

Hi @PawelRTE,

I'm glad you were able to solve your problem.  I read your request and wanted to respond.  We are following the specification when it comes to the authorization response for OAuth2 authorizations.  The Authorization Code Grant Flow response does not return the scopes authorized by the user, https://tools.ietf.org/html/rfc6749#section-4.1.2, while the Implicit Grant Flow response does return the scopes, https://tools.ietf.org/html/rfc6749#section-4.2.2.  

Depending on the OAuth2 library you're using, you still might be able to retrieve the scopes authorized by the user for the Authorization Code Grant Flow.  For example, the scribejava OAuth2 library has a method called getRawResponse() which will return the details of the access token, including the scopes authorized by the user.  Check if the library you're using has similar functionality.  If not, our tokens use the JSON Web Token (JWT) format.