UnexpectedError when calling /history/devices endpoint

Hi

I have been using the /history/devices?locationId=x endpoint for users of the www.constantgraph.com website to get access to their history data. For most users this works fine having obtained an oauth token for authentication. However, I have one user who is getting the following response (with code 403):
{
“requestId”: “4953759559098292733”,
“error”: {
“code”: “UnexpectedError”,
“message”: “A non-recoverable error condition occurred: Forbidden”,
“details”: [ ]
}
}

I have checked the access key which works fine with other API requests and I have also asked them to renew the oauth key which has not helped. This is a different response than if I put in an incorrect bearer token which gives this response:

<html>
<head>
    <title>401 Authorization Required</title>
</head>
<body>
    <center>
        <h1>401 Authorization Required</h1>
    </center>
    <hr>
    <center>openresty</center>
</body>
</html>

Putting in an incorrect location also gives a different error. I thought it might be to do with authentication scopes which are set to r:devices:*, r:locations:* but as it works fine for other users I’m not sure how that could be. Any ideas how to resolve this?
Note that for premium users event subscriptions are used which is clearly a better approach but can be a lot more hungry on server resources.

Thanks

Simon

Hi @constantgraph

Could you please try again and share the timestamp (with your timezone) and the request ID so the team can take a deeper look?

Thanks!

Hi. Thanks both your your insights. I’ve been working in the background with the customer on this (who has been very helpful!) and it turns out that they unselected “Allow (read) on all devices” during the OAuth flow and instead selected some specific devices.

As I query the history API by location only and not device this is what was causing the problem and it would be impractical to query by device. Interestingly, I was not able to create any CAPABILITY subscriptions using the supplied OAuth token either even when the capability matched the capability of one of the allowed devices. Presumably because there were other devices with the same capability that were not included. Subscriptions have to be done on a CAPABILITY basis rather than device as the max subscription limit is too low to work at device level.

I am now putting an extra page on the site giving the user to select which capabilities they want and warning against unselecting the defaults on the SmartThings flow. Unless you have any better suggestions on how to handle the situation?

Hi,
Subscriptions of that type require the “read all devices” permission, which is why it couldn’t be created. I think your solution of asking users to grant access to all their devices is appropriate.

You can find more details in the official documentation here: API | Developer Documentation | SmartThings