OneNote Graph API: lastModifiedDateTime returned identical to createdDateTime after page edits (regression)

Question

We are seeing a regression in the Microsoft Graph OneNote API where lastModifiedDateTime on a page entity is returned identical to createdDateTime (same instant, to the second) even after the user has made multiple edits to the page. This started a few days ago and is reproducing across multiple tenants.

What I expect

After a user edits a OneNote page, lastModifiedDateTime should advance past createdDateTime.

What I'm seeing

lastModifiedDateTime == createdDateTime, byte for byte, on pages that have demonstrably been edited.

• The OneNote web client and desktop client both show the page has been edited recently.
• GET /me/onenote/pages/{id}/content returns the user-authored body.
• Only the timestamp fields on the page entity are wrong.

Affected endpoint

1. List endpoint — GET /me/onenote/pages/{page-id}

{
  "id": "[Moderator note: personal info removed]",
  "title": "1 - Welcome and Introduction",
  "createdDateTime":      "2026-06-02T11:03:06Z",
  "lastModifiedDateTime": "2026-06-02T11:03:06Z"
}

Response headers:

| Header              | Value                                                                                                                     |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| request-id        [Moderator note: personal info removed]`                                                                                    |
| client-request-id   | `[Moderator note: personal info removed]`                                                                                    |
| x-ms-ags-diagnostic | `{"ServerInfo":{"DataCenter":"Central India","Slice":"E","Ring":"3","ScaleUnit":"000","RoleInstance":"PN1PEPF0001654D"}}` |

Repro steps

1. Authenticate as a delegated user with Notes.ReadWrite.
2. Create a OneNote page via Graph (or via the OneNote client — both reproduce).
3. Open the page in OneNote (web or desktop) and add several lines of content over a few minutes; save each edit.
4. Confirm in the OneNote UI that the page shows recent modifications.
5. Call GET /me/onenote/pages/{page-id} (or the section's pages list).
6. lastModifiedDateTime equals createdDateTime exactly.

Already ruled out

• Not a caching / If-None-Match issue — no conditional headers; fresh 200 OK each time.
• Not a $select projection issue — full default entity returned.
• Not an auth / permission issue — content endpoint returns the edited body fine.
• Not specific to one notebook, section, or user — reproduces across multiple users, sections, and tenants.
• Not a client-clock issue — timestamps are server-generated UTC.

Impact

Our product uses the delta between createdDateTime and lastModifiedDateTime to detect which pages have been edited by the user. With the two values collapsed, the heuristic returns "no edits" for every page, and a customer-facing indicator goes silent. Affecting multiple tenants in production.

Questions

1. Is there a known regression in the OneNote page-metadata path causing lastModifiedDateTime to mirror createdDateTime for edited pages?
2. Has the field's update semantics changed recently — does it now require a different write path (e.g. PATCH vs. the OneNote sync client's writes) to advance?
3. Recommended alternative signal to reliably detect "page has been edited" until this is resolved — e.g. ETag on the page entity, pages/{id}/content length, OneNote change-notification subscriptions?

Happy to provide more request-id / client-request-id values from additional reproductions if useful.

Answer 1

Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

We're not Microsoft support; this is a user-to-user support forum. Moderators have no backend access and cannot directly intervene in Microsoft products. We provide only technical guidance and best-practice recommendations based on reported issues

Hi @Prakash Verma

I completely understand how critical this is, especially since your change-detection heuristic relies on the delta between these two timestamps, and the current behavior is causing a customer-facing indicator to go silent across multiple tenants.

After researching this behavior, there is currently no official public documentation or notice indicating that the update semantics of the lastModifiedDateTime field have changed, or that this behavior is expected. Since the OneNote web and desktop clients display the correct modification states while the API endpoint returns identical timestamps, this appears to be an unexpected metadata discrepancy on the server side.

Since this situation is impacting your production environment, you can implement an alternative validation flow to accurately track page updates without relying on the page-level timestamp.

Instead of polling the content of every single page (which could lead to throttling), you can use a two-tiered validation approach using the parent Section's metadata:

1. Monitor the Parent Section: The lastModifiedDateTime on the parent onenoteSection object usually continues to update normally when any page within that section undergoes modifications. You can periodically check the section metadata: GET /me/onenote/sections/{section-id}
2. Trigger Selective Content Fetching: When you detect that a section's lastModifiedDateTime has advanced, it signals that an update occurred within that container. At this point, retrieve the content of the pages within that specific section: GET /me/onenote/pages/{page-id}/content
3. Compute and Compare Content Hashes: Compute a cryptographic hash (such as SHA-256) of the incoming <body> content of the page. Compare this payload hash against a previously stored hash linked to that specific page-id in your database.

By filtering your checks through the section-level timestamp first, you eliminate unnecessary data processing. You only fetch the full-page content when you confirm a change occurred somewhere in the section, allowing you to accurately detect exactly which page was edited.

However, I highly encourage you to submit your detailed report, especially your excellent "Expected behavior" and "Suggested solutions" sections directly to the official GitHub repository.

Reporting this on GitHub is the most effective way to flag this usability gap to the experts who design the schema and the Teams rendering engine, allowing them to provide further insights or log it as an official feature request.

I hope this helps.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click ""Comment"".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

The behavior described cannot be confirmed or explained from the available documentation. The context only states the intended semantics of the timestamps (created vs. last modified) and how to work with pages efficiently; it does not mention any regression, behavioral change, or alternative signals for detecting edits.

The only directly relevant guidance is:

• createdDateTime is “the date and time when the page was created.”
• lastModifiedDateTime is “the date and time when the page was last modified,” stored as an ISO 8601 UTC timestamp and documented as read-only.
• For large notebooks, page retrieval should be done per-section and can be ordered by createdDateTime instead of lastModifiedDateTime for performance, but this is a performance optimization, not a change in semantics.

There is no information in the context about:

• Any known regression where lastModifiedDateTime equals createdDateTime after edits.
• Any recent change in update semantics (e.g., requiring a particular write path) for lastModifiedDateTime.
• Any recommended alternative signal (such as ETag, content length, or change notifications) specifically for OneNote page edit detection.

Because of this, the questions about a current regression, changed semantics, or recommended temporary workarounds cannot be answered from the provided material.

---

References:

• Best practices for working with the OneNote API in Microsoft Graph
• MicrosoftGraphOnenotePage Class
• MicrosoftGraphOnenoteEntityHierarchyModel Class
• Create OneNote pages
• Update-MgBetaSiteOnenoteSectionGroupContent
• Application interface (OneNote)