Share via

Microsoft Graph sitePage publish endpoint returns itemNotFound but page is successfully published

Jose Eduardo 0 Reputation points
2026-05-26T22:31:56.8633333+00:00

We are experiencing an inconsistent behavior with the Microsoft Graph SharePoint Pages API.

We are using the documented endpoint:

POST /sites/{siteId}/pages/{pageId}/microsoft.graph.sitePage/publish

Documentation reference: https://learn.microsoft.com/en-us/graph/api/sitepage-publish?view=graph-rest-1.0

Scenario:

  1. Create a SharePoint page via:
       POST /sites/{siteId}/pages
    
    Response is successful (201 Created) and returns a valid page object, including:
{
  "id": "[Moderator note: personal info removed]",
  "name": "example.aspx",
  "publishingState": {
    "level": "checkout"
  }
}

2- After, publish the same page using:

POST /sites/{siteId}/pages/{pageId}/microsoft.graph.sitePage/publish

Expected behavior:

HTTP/1.1 204 No Content

Actual behavior:

Response:

{
  "error": {
    "code": "itemNotFound",
    "message": "Item not found",
    "innerError": {
      "date": "2026-05-26T21:57:31",
      "request-id": [Moderator note: personal info removed],
      "client-request-id": "[Moderator note: personal info removed]"
    }
  }
}

However, despite the error:

  • the page IS actually published
  • publishingState.level changes from checkout to published

Additional validation performed:

  • same behavior reproduced in application code and Postman
  • same bearer token used
  • app permissions correctly configured
  • GET page endpoint works with the same pageId
  • retries with delays do not change the behavior

This suggests the publish operation succeeds internally but Graph returns an incorrect error response.

Has anyone seen this behavior before? Is this a known issue with the SharePoint Pages API?However, despite the error:

  • the page IS actually published
  • publishingState.level changes from checkout to published

Additional validation performed:

  • same behavior reproduced in application code and Postman
  • same bearer token used
  • app permissions correctly configured
  • GET page endpoint works with the same pageId
  • retries with delays do not change the behavior

This suggests the publish operation succeeds internally but Graph returns an incorrect error response.

Has anyone seen this behavior before?
Is this a known issue with the SharePoint Pages API?

API version tested: v1.0
Tenant type: SharePoint Online

Microsoft 365 and Office | SharePoint | Development
0 comments No comments

1 answer

Sort by: Most helpful
  1. Michelle-N 16,635 Reputation points Microsoft External Staff Moderator
    2026-05-27T14:24:50.1266667+00:00

    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.

    Hi @Jose Eduardo

    Based on the information provided, I understand that you are experiencing an unexpected behavior with the Microsoft Graph SharePoint Pages API (v1.0) on SharePoint Online. After successfully creating a site page, calling the official publish endpoint POST /sites/{siteId}/pages/{pageId}/microsoft.graph.sitePage/publish returns an unexpected 404 Item not found (itemNotFound) error response instead of the expected 204 No Content. However, despite this error, the page is successfully published on the backend and its state changes from checkout to published. This behavior is fully reproducible in both code and Postman, and introducing delayed retries does not resolve the response mismatch.

    This behavior points toward a timing and synchronization mismatch between Microsoft Graph and the underlying SharePoint Online backend architecture:

    The page publishing mechanism in SharePoint is an internal asynchronous process. Microsoft Graph acts as an API wrapper over this legacy architecture. When you trigger a publish command, Graph sends the instruction down to SharePoint.

    Once SharePoint successfully processes the internal state transition from checkout to published, Microsoft Graph immediately attempts to do a backend lookup or replication verification to confirm the status before generating its response. If the search index or database replica has not yet achieved absolute consistency, Graph fails to find the expected version state during that microsecond lookup and throws an itemNotFound exception.

    While this gets reviewed by the Microsoft product groups, you can bypass this behavior using one of the two standard workarounds below:

    -Implement False-Positive Exception Handling

    Since the action completes successfully despite the message, you can modify your code's error-handling block to treat itemNotFound at this specific endpoint as a successful trigger, followed by a programmatic verification:

    Treat "itemNotFound" on this specific endpoint as a false-positive. After calling publish, always follow up with a GET on the page and check the publishingState. Example pseudo-code:

    POST /sites/{siteId}/pages/{pageId}/microsoft.graph.sitePage/publish// ignore itemNotFound errorGET /sites/{siteId}/pages/{pageId}// if publishingState.level == "published" → success
    

    -Transition to the Native SharePoint REST API (_api/sitepages)

    Many development teams tracking this specific Graph instability choose to bypass the Graph wrapper entirely for publishing tasks, as the native SharePoint REST API interacts directly with the content database and handles state consistency much better:

    • Endpoint: POST {siteUrl}/_api/sitepages/pages({pageId})/publish
    • Payload: This endpoint requires no request body and reliably returns an explicit 200 OK status code once the publication state commits.

    Please let me know if you require any help.


    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.

    Was this answer helpful?


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.