The Notebook id
isn't surfaced through the DriveItem
resource. They're returned by the API so it acuratly reflect the same files returned by the OneDrive UI but they're not meant to be interacted with directly. For working with Notebooks, you need to use the Notes API.
The OneDrive Documentation is a bit more direct on this topic:
Working with OneNote Notebooks
Note: Although OneDrive stores OneNote notebooks, you shouldn't use the OneDrive API to work with OneNote notebooks.
This doc set also includes a more complete description of the Package resource type.
At the moment there isn't a simple method to uncover a Notebooks's id
from it's corrisponsing DriveItem
. There is one trick you can use, but fair warning, this is not a documented method.
Using Graph Explorer (without loging in), execute the following call:
https://graph.microsoft.com/v1.0/me/drive/items/01BYE5RZ35EU76DRTYZ5DK5DATNBSRPLC7
Look at the eTag
in the result:
"eTag": "\"{E13F257D-78C6-46CF-AE8C-13686517AC5F},1\""
Now take a gander at the list of Notebooks using:
https://graph.microsoft.com/v1.0/me/onenote/notebooks
The first Notebook returned has the following id:
"id": "1-e13f257d-78c6-46cf-ae8c-13686517ac5f",
When you look at these side-by-side, you'll notice the Notebook's id
contains the same data as the eTag
, albeit in a slightly different order ({digit}-{guid}
):
"eTag": "\"{E13F257D-78C6-46CF-AE8C-13686517AC5F},1\""
"id": "1-e13f257d-78c6-46cf-ae8c-13686517ac5f",
I've used this myself but I would be careful and make sure your code used more than just the eTag
(I looked at the eTag
, the owner
, and the name
properties). It isn't "supported" so it's possible this could change so comparing multiple properties could prevent a mishap down the just.
Oh, and don't tell anyone. This is just between us. ;)