Common Solutions
chevron down
back search icon cancel search
 
 

Common Solutions

Authorization Issues

Error “Sorry it’s not you… It’s us”

The error “Sorry it’s not you… It’s us” while authorizing the connection can be caused when the redirect URI or callback URL is not absolute.

In the OAuth 2.0 Authorization Framework spec, RFC6749 section 3.1.2 states

The redirection endpoint URI MUST be an absolute URI as defined by RFC3986 Section 4.3. The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component (RFC3986 Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.

RFC3986 Section 4.3 defines the absolute URI to be:

absolute-URI = scheme ":" hier-part [ "?" query ]

If the redirect or callback URI includes just the scheme (i.e. myapp://), but not the hier-part of the redirect URI, then this error will occur. Try changing the redirect URL from myApp:// to a specific entry point in your application (i.e. myApp://callback)

Data Synchonization Issues

Fitbit user has multiple accounts

Data synchonization problems, between the Fitbit user's account and a 3rd party application, can be observed through different experiences:

  • The Fitbit user sees steps in their Fitbit account but the data is not syncing to the 3rd party application.
  • An endpoint returns an empty response when the Fitbit user is believed to be active and data exists.

Most of the time, these types of data syncing issues are caused by the Fitbit user unintentionally creating and using multiple Fitbit accounts. The user will pair their device with one account, and consent to share their data with another. Follow these steps to find the user's Fitbit user ID, then verify it matches the user ID paired with your application.

NOTE: A Fitbit user should never provide 3rd party developers with their email address. Do not ask for this information from the Fitbit user.

Fitbit mobile application for iOS and Android

Ask the user to follow these steps to find their user ID within the Fitbit mobile application

  1. Open the Fitbit mobile application
  2. Tap on the profile picture on the upper left hand corner of the screen
  3. Tap on the profile name.
  4. Tap on "Personal"
  5. At the bottom of the page is the user ID

Fitbit.com Web Dashboard

Ask the user to follow these steps to find their user ID within the Fitbit web application.

  1. Go to https://www.fitbit.com and log into the Fitbit account
  2. Click the person icon -> "My Dashboard"
  3. Click on the "View Profile" icon
  4. The user id is found in the URL search bar

List the applications the user is sharing their data

The user may believe they have consented to share their Fitbit data with your application. You can have the user confirm by looking at the list of applications they have authorized.

Fitbit mobile application

  1. Open the fitbit mobile (iOS/Android) application
  2. Tap on the profile picture in the upper left corner of the screen
  3. Tap on "Third Part Apps" -> "Manage Applications"
  4. The user will be redirected to the fitbit.com website and prompted to log in
  5. The user will be presented with a list of 3rd party applications they've consented to share data with

Fitbit web application

  1. Go to https://www.fitbit.com and log into the Fitbit account
  2. Click the person icon -> "My Dashboard"
  3. Click on the gear icon located in the upper right hand corner of the page, and choose "Settings"
  4. On the left hand side of the page, click "Applications". All the applications the user is sharing their Fitbit data are listed.
NOTE: If the 3rd party application is not listed, this Fitbit user is not sharing their data with the application. We recommend the Fitbit user complete the steps above to verify the correct Fitbit account is used. Afterwards, the user may need to complete the application's authorization flow.

Refresh Token Issues

Error “Invalid refresh token”

The error “Invalid refresh token” can be caused by one of the following scenarios:

  • Using the refresh token endpoint on the wrong client ID.
    The refresh token is associated with the client ID on which it is was created.

  • Trying to use the same refresh token multiple times.
    The refresh token can only be used once. After it has been used, it becomes invalid.

  • Trying to use multiple refresh tokens for the same user
    A user may have multiple active access tokens for a single application. However, each user may only have one active refresh token. When a new access token is created, the associated refresh token becomes the new active refresh_token, replacing the previous refresh token.

Subscription/Webhook Issues

Cannot verify the subscriber endpoint

When pressing the "Verify" button, Fitbit sends your subscriber endpoint 2 GET requests. The first GET request will contain your verification code (see picture). Your application needs to reply with a 204 response. The second GET request will contain an intentional invalid code. Your application needs to reply with a 404 response.

Once both of these responses have been received by Fitbit, your subscription endpoint should be verified.

Application is not receiving subscription / webhook notifications

There are seveal reasons why an application is not receiving the subscription / webhook notifications. Here is a list of things to verify within your environment:

  • Can you ping the subdomain from outside your network?
  • Decode the access token within http://jwt.io to verify the Fitbit user consented to share the requested data.
  • Has the Fitbit user synced their data in the last 7 days?
  • Within https://dev.fitbit.com, has your subscriber endpoint been disabled? If it has been disabled, re-enable the subscriber endpoint.
  • Is your subscriber configured to support TLS v1.2?
previous
Web API Explorer