OneDrive webhook API occasionally returns a 401 status code

TL;DR: scroll down to the "Questions" section

Hello, I am currently working on an integration with OneDrive that manipulates webhook subscriptions to OneDrive drives via the Graph API, using the /subscriptions endpoint.

Sometimes, without any apparent reason, the API returns a 401 Unauthorized error with a response similar to the one below (this one is the payload of an actual response I got for a PATCH /subscriptions/{id} call):

{
    "error": {
        "code": "ExtensionError",
        "message": "Operation: Update; Exception: [Status Code: Unauthorized; Reason: Authentication failed]",
        "innerError": {
            "date": "2021-04-16T00:29:11",
            "request-id": "4f1f55fe-9ac1-4c8c-9d21-529d0d0be1a1",
            "client-request-id": "4f1f55fe-9ac1-4c8c-9d21-529d0d0be1a1"
        }
    }
}

Retrying the request usually works (yes, retrying the exact same request that returned a 401 Unauthorized error can succeed if retried). To demonstrate this, I attached the logs of 2 other, identical requests: one that failed and another one that succeeded. I obfuscated the auth tokens, but assume that the exact same auth token was used for both. Also assume that the endpoint indicated in the payload existed at the time, and correctly performed the validation steps outlined in the documentation.

Given that the response payload and headers don't provide any useful information (even the x-ms-ags-diagnostic header is identical between a successful and a failed request), and that the documentation does not mention anything specific to these endpoints and their status codes I wanted to reach out to the community to check if anyone else faced a similar issue.

==Questions==

Did anyone experience intermittent 401 Unauthorized status codes from the OneDrive /subscriptions endpoints? If so, how did you handle them?

The naiive approach would be to retry the request, except that the outcome of a request that returns a 401 Unauthorized status code is uncertain. For example, sometimes the webhook gets eventually created even when a POST /subscription request apparently fails. Given the nature of the problem, it's hard to come up with a consistent way to test this, but if I discover more information I'll update this post.

Thanks!