401 Unauthorized error for OPTIONS preflight requests (April 2025)

[jl__]

My users are reporting errors that just started happening today (April 18) where requests to activities and timeseries APIs like https://api.fitbit.com/1/user/-/activities/date/<date>.json are getting a 401 Unauthorized response (no error message or error details) to the CORS OPTIONS requests. Some other APIs like goals and profile are working.

This breaks functionality for our users since we make requests from the browser rather than a backend server.

[GordonFitbit]

Hi @jl__ 

I don't see any 401 errors from your application.   Let me reach out to you directly through issue tracker to get some additional information from you.

[kellerch]

We're seeing the same issue in our application. Any activity endpoint calls (e.g. https://api.fitbit.com/1/user/-/activities/steps/date/<date>/<date>.json ) are getting rejected with a 401 Unauthorized in the OPTIONS preflight request. I'm not sure how long it has been happening, but it was reported to us yesterday. Was there any progress made on figuring out the issue when you reached out directly to the OP? We are also making requests in the browser and not from a backend server.

[PressPlay]

I'm also seeing the same issue in our application. Any resolution so far?

In my case we're hitting the `https://api.fitbit.com/1.2/user/-/sleep/list.json` endpoint. We're getting 401 Unauthorized from the OPTIONS pre-flight request. This was previously working (last tested perhaps 1-2 weeks ago) – no changes made to our codebase.

We are also making requests in the browser and not from a backend server, testing in Chrome.

As a note, the introspect endpoint `https://api.fitbit.com/1.1/oauth2/introspect` responds with 200 OK prior.

And the call works from Postman (where no pre-flight request is sent).

[PressPlay]

Hi, I'm still having this issue. Any help would be appreciated. This is breaking our app for customers.

[carrotflakes]

Try https://api.fitbit.com/1/user/-/sleep/list.json .
This worked for me.

[PressPlay]

Hi @carrotflakes this does work, thanks for the temporary workaround.

I can use this for now however, functionality is still broken because the data from this version of the API has a few differences, namely:

• Data structure and naming differences.
• No isMainSleep field.
• Granular data doesn't show light, REM, and deep sleep.

@GordonFitbit any chance the original issue with the unauthorized preflight be looked into?

[jl__]

I wrote this on the issue tracker, but since there's no progress on there, I'll repeat my notes here:

---

To fix this, the API needs to:

1. Return 200 OK for OPTIONS requests. The OPTIONS requests are not performing any actions, so they don't need authentication (the browser spec in fact prohibits sending authentication with OPTIONS requests).
2. The OPTIONS response headers should have the appropriate Access-Control-Allow- headers to let the browser know that it can use those methods/headers. You can look at at https://api.fitbit.com/1/user/-/profile.json response for the correct headers, which are:

Access-Control-Allow-Headers: Accept,Authorization,Content-Type,Device-Data-Encoding,Fitbit-Code-Version,Fitbit-Transport-Info,Origin,X-App-Version,X-Requested-With,Accept-Locale,Accept-Language
Access-Control-Allow-Methods: GET,PATCH,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Origin: <the origin that was sent with the request>

(Ideally it'd also allow access to Fitbit-Rate-Limit-Limit,Fitbit-Rate-Limit-Remaining,Fitbit-Rate-Limit-Reset)

As mentioned, the CORS OPTIONS headers/responses work correctly on APIs like profile, and previously worked until April 18 or so, but recently broke on timeseries and activity APIs.

---

[njvnba11]

Just wanted to add more weight to this request.

I also cannot call the activities endpoint (/1/user/-/activities.json) with a browser API call, even through the web-api explorer. I get the 401 unauthorized error on the OPTIONS preflight request which then blocks the browser from calling the endpoint because no CORS Access-Control-Allow-Origin is present in the response.

Screenshots from web-api explorer with network and console browser tools: