Share via

Microsoft Graph API for OneNote not updating LastModifiedDateTime

Troy 0 Reputation points
2026-06-03T17:17:35.1533333+00:00

This is follow-up on a known case with a case number that was resolved in 2024, but has come back. Since we're not supposed to provide private data, I'm not including all the history.

What is happening:

  1. User updates OneNote
  2. Our service polls API or is expecting a webhook with updates
  3. Webhook is either not sent or when polling API returns no updates and shows LastModifiedDateTime for the page that is same as creation date of the page. Essentially, updates happening and visible in the app are not accessible via the API.

Our service relies on LastModifiedDateTime to exclude processing notes with no changes, so we would incorrectly exclude pages when this field is not updated. Worse, the actual page changes are not updated either so when we manually pull a page, the changes aren't reflected.

Based on our previous experience with Microsoft on this issue, it is related to where notebooks are stored so it doesn't effect all users or even the same user with notebooks stored in different places. However, we've received enough complaints to confidently say the issue is back.

Microsoft Security | Microsoft Graph
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rayyan Fawad 0 Reputation points
    2026-06-04T23:35:32.39+00:00

    Hi Troy, the recurrence of the Microsoft Graph API failing to update the LastModifiedDateTime property and dropping webhook sync signals a known, localized regression in how the API syncs changes from specific OneDrive or SharePoint storage clusters. Since the page updates are visible in the client application but completely invisible to downstream API requests, your polling and exclusion logic is hitting a stale data cache on the server side. To resolve or bypass this issue while Microsoft flags the regression internally, you should temporarily alter your synchronization payload to request the delta link state (/onenote/pages/delta) if supported by your endpoint, or force a cache-busting header like Cache-Control: no-cache in your standard page-pull requests to bypass the stale server-side indexing. Additionally, because this bug is highly dependent on the notebook's specific backend storage location, moving a heavily affected notebook to a different SharePoint site or a fresh OneDrive root folder frequently forces the Microsoft Graph backend to rebuild its webhook event triggers and index the modified timestamps correctly again.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.