500 error while calling API from local host

[Leeseonghwan]

Language : Javascript

Env : Window 10, Node.js, React JS  

Simulator : MS Edge(Chrome)

Application ClienID : 22C6TY

Use Flow : Implicit Grant Flow

When calling the API in 127.0.0.1:xxxx/ as follows:

async function fetchData(){
  await fetch(`API`, {
    method: "GET", 
    headers:{
      Authorization : `Bearer ${Access Token}`,
    },
  }).then((response) => response.json()).then((data) => console.log(data))
}

The API that calls the following user's profile works fine, 

API = https://api.fitbit.com/1/user/-/profile.json

(Except profile) all of other APIs are called, the call fails with a 500 error.

API = https://api.fitbit.com/1/user/-/badges.json
      https://api.fitbit.com/1/user/-/activities/date/2021-05-12.json
      .....

-------------------------------------------------------------------
response:

GET https://api.fitbit.com/1/user/-/badges.json 500

{errors: Array(1), success: false}
  errors: [{errorType: "request", fieldName: "n/a", message: null}]
  success: false
  __proto__: Object

what should I do? help me please FITBIT dev 😢

[Gordon-C]

Hi @Leeseonghwan 

I would like to try to reproduce this problem for our engineering team.  Would you please provide me with the detailed steps, including the endpoints and headers, you followed to get this error?    I've tried on my own and do not see the same behavior.

Thanks!

Gordon

[GeekOfChoice]

I get the 500 error as well, whether through Python (on my local machine), Postman (postman.co), or fitbit's Swagger Site (https://dev.fitbit.com/build/reference/web-api/explore/#/Activity%20Intraday%20Time%20Series/getActi...)  Just like Leeseonghwan wrote, the profile endpoint works fine (https://api.fitbit.com/1/user/-/profile.json).  All others return a 500 response with 

{
"errors": [
{
"errorType": "request",
"fieldName": "n/a",
"message": null
}
],
"success": false
}

[Gordon-C]

Hi @GeekOfChoice 

Thank you for providing the additional information.   Would you please private message me the user id which is generating the 500 error?   I'm trying to find a pattern that is causing this problem.

[Gordon-C]

Did either of you happen to press the "Reset Client Secret" button prior to the 500 errors occurring?   I'm curious if this is part of the steps to reproduce the problem.

[angrybeard]

I encountered the same 500 error and then I pushed Reset Client Secret in an attempt to 'start over', but I received the same error. 

[GeekOfChoice]

Yes, I'm almost certain I did.  I clicked it accidentally.  I didn't think it was a big deal.  Sounds like maybe it was!

[Gordon-C]

Yes...resetting the client secret seems related to the problem.   I'm working with the engineering team to provide a fix.   Right now, the only workaround I see is to re-register your application again.   

[Gordon-C]

UPDATE: I mentioned a workaround of registering your application.  Keep in mind, if you do this all of your users will need to re-consent to share their data with your application.   I recommend only doing this for test applications.

We have found the problem and working on the fix.   If everything goes as planned, the problem should be resolved on Monday, May 24th.   I'll post an update here once the fix has been posted.

Thank you for your patience.

[angrybeard]

Your workaround did indeed work. I am able to pull heart rate to local host now. Thank you for the quick solution and fix!

[Leeseonghwan]

The method using the "Reset Client Secret" button doesn't work 😢

In the case of me, it is a situation where the procedure for the experiment plan and method has been completed in order to acquire intraday data for several people.

It takes 3-4 days to repeat the process of creating a new application and registering it again, which is a rather complicated process.

How to wait for the update until May 24th, or register and use a new application. The time required for the two methods seems to be similar...

If I create a new application, can I skip the existing Intraday data acquisition process?

Thank you so much for your kind and quick response @Gordon-C 😊

[GeekOfChoice]

Sounds like @angrybeard had success with this method.  I'll give this a try when I get a chance.  I'm the only user of my app, so I don't expect any issues.  I just use this to programmatically download my data and gain some API experience.  Thank you for your help @Gordon-C !

[Gordon-C]

Hi @Leeseonghwan 

Based on your use case, I would recommend waiting until the fix comes outs next week.   Thank you for your patience.

[GeekOfChoice]

I couldn't figure out how to re-register my app (which isn't a real app/website - it's just set up so I can access the API), so I simply created a second one.  I got a new client ID and used that in my API call to https://www.fitbit.com/oauth2/authorize. I got my new access token and passed it in an API activity endpoint call in a manner similar to Leeseonghwan's fetchData() function in the initial post above, and everything works fine now.  Thank you all for your help!

[Gordon-C · Accepted solution]

** This is only needed if you recently reset your client secretand all of the endpoints are failing except for the Get Profile endpoint **

Hi everyone.   We pushed the fix this morning.   I've tested it and it worked.    To have the fix applied to your application, you will need to reset your client secret by pressing the "Reset Client Secret" button on the summary page of your registered application.   

Once you reset your client secret, you will need to change the client secret value in your code where you build the basic token.   Your existing connected users will not need to re-consent with your application.  

If you have any problems, please let us know.

[Leeseonghwan]

Ohh Has been resolved.

It works without problems!! Thank you:)

If we have any other problems, we will come back.

Thanks fitbit @Gordon-C 😊😊

[GeekOfChoice]

I tested this fix on both my original app (which was still failing) and my "workaround" app, which was working fine.  I changed the Client Secret on both, and now I have two apps which are working fine.  Thank you @Gordon-C and team!