My code calls the OneNote API to retrieve a list of notebooks in an O365 SharePoint site. We get a bearer token, set the HTTP auth header and issue a GET request to:
https://www.onenote.com/api/v1.0/myOrganization/siteCollections/1165b017-ce4b-4b01-9e0c-d1ed91827b33/sites/99d8f75e-c7eb-4de1-a304-86f567c1ce99/notes/notebooks
This usually works, but yesterday it intermittently returned an HTTP 500 response, and today it returns a 500 response every time :(
We capture all the HTTP headers on the response, including the X-CorrelationId - here's one from today:
X-CorrelationId: dbcff391-6767-451c-a011-05fb8d2a0e32
The FromUrl API call that resolves a URL -> SharePoint SiteId, we now make once and cache for a long time as that mapping is pretty much static. The notebooks in a site however can change often as users create/delete/rename them, so we need to get fresh data every time. Is the OneNote API fundamentally unstable?
EDIT
We have noted that it might be the availability of the user's OneDrive for Business. I believe that these OneDrives are SharePoint doc libraries under the covers, created on-demand when a user first accesses it. We appear to be getting 500 responses for users that have never accessed OneDrive before, but success for users that have. On the face of it, this seems pretty clear: the user must have accessed their OneDrive prior to the OneNote API call, else it returns 500.
However, this appears inconsistent between tenancies: we have one O365 tenancy where this is not the case and the API returns successfully even if the user has no OneDrive. So my questions are: 1) should the availability of the user's OneDrive make a difference, and 2) why does this vary between tenancies?
EDIT #2 This has been confirmed by Microsoft developer support escalation engineer - the API requires the user to already have a OneDrive. This is a bug as the API call should be listing the OneNotes in an external SharePoint doc library, so should not care whether the user has a OneDrive provisioned for them. I understand it is on the backlog for them to fix...