Sleep Endpoint Meta Response Retry

[Jeff_New_Ocean]

Hi Team,

We have noticed recently that we are receiving a high percentage of requests to the sleep log endpoint

GET /1.2/user/[user-id]/sleep/date/[date].json

That are returning this meta response indicating that we should retry.

Over the last month, approximately 9,000 of 38,500 requests, or 23% of requests.

I don't have any historical numbers, but I don't recall seeing very many of the meta responses until recently. And definitely not during checkout after initial testing.

However, given that the architecture is such that we are requesting the sleep data in response to the Fitbit notification that the data is available, this seems excessive. The documentation states:

Some of the sleep log processing occurs asynchronously. On rare occassions [sic], your application may be querying the sleep logs while the sleep data is still being processed. If the sleep logs are still in a processing state, a "meta" response will be returned...

We didn't implement a retry process for this scenario (based on the "rare occasions"), but we do have a nightly reconciliation process in place to capture any missing data for the day. However, this does cause an apparent delay in data processing to the end user.

I did see this previous topic: https://community.fitbit.com/t5/Web-API-Development/Sleep-API-Sending-notifications-when-the-new-sle..., but I wanted to alert you of this just in case there is an issue on your end.

Can you advise?

Thanks,
Jeff Humphry
New Ocean Health Solutions

[JohnFitbit]

Hi @Jeff_New_Ocean, 

Are you saying that your retry requests have increased due to the increased volume of "meta" responses? Can you provide me with an example of these responses and the updated response after the data was reconciled? Additionally, if you can provide me with a timestamp of when you received a sleep notification, the timestamp of when you called the sleep api, the initial meta response you received, and then the updated reconciled response you received.

I know that it might not be consistent across all users, but there may be a processing delay depending on what the Fitbit user is tracking. There are several data points that rely on a valid sleep stage log, such as, HRV, SPO2, Breathing rate, and Temperature.

In the meantime, I will reach out to engineering to see if they are aware of any changes to the Sleep API.

[Jeff_New_Ocean]

Thanks @JohnFitbit for the quick response.

Actually, we are not retrying based on the meta response. We had decided that if this was supposed to be a rare occurrence, to allow the nightly reconciliation process to retrieve the missing data.

What we did noticed is, during recent testing, an increase in the number of users reported that are not showing sleep data until next day.

If you still want a sample meta response example:

GET https://api.fitbit.com/1.2/user/{UserId}/sleep/date/{date}.json

{
    "meta":{
        "retryDuration":3000,
        "state":"pending"
    },
    "sleep":[
        
    ],
    "summary":{
        "totalMinutesAsleep":0,
        "totalSleepRecords":0,
        "totalTimeInBed":0
    }
}