Microsoft 365 Copilot Retrieval API returns empty results after pay-as-you-go activation

Hello @beguem

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Thank you for sharing the detailed observations and sensitivity label configuration. The behavior described helps clearly narrow down the scenario.

From the validation provided, the following is confirmed:

• The Retrieval API request is successfully processed (HTTP 200)
• Authentication and permissions are valid
• Graph Search returns the same SharePoint content
• Retrieval API and Foundry grounding execute but return empty results

This confirms that the issue is not related to connectivity or permissions, but rather how content is processed for AI grounding.

The difference lies in how each service works:

• Graph Search API returns documents from the search index (discovery)
• Copilot Retrieval API returns text extracts used for grounding AI responses

Therefore:

• Appearance in search confirms indexing and access
• Empty retrievalHits indicates that no usable grounding content was produced

The Retrieval API depends on the Copilot semantic index and grounding pipeline, which processes and extracts content rather than returning documents directly.

As per the guidance and observed behaviour -

1. Content protected with user-defined permissions can block Copilot and agents from extracting content
2. Unopened SharePoint documents with such protection may not be accessible to background grounding scenarios

Regarding the preview limitation and architectural constraint - the behavior aligns with current service behavior / known limitation scenarios for background grounding.

• It is not an indexing or permission issue
• It is not documented as a permanent constraint
• As the Retrieval API is in preview, behavior may evolve

However, no official commitment or change timeline is published.

Supported configurations that can be validated include:

Yes, supported configurations that can be validated include:

• SharePoint-permission-based access (no user-defined encryption)
• Default sensitivity labels at the document library level
• Labels that extend SharePoint permissions to documents

These configurations allow content to be processed more reliably by the grounding pipeline.

Regarding the reason for native Copilot working while Retrieval API does not is that

The difference is due to processing paths:

Native Copilot (interactive)

• Works with content when opened (“data-in-use”)
• Applies user permissions at runtime

Retrieval API / Foundry grounding

• Performs background retrieval
• Depends on semantic indexing and extractable content

Because of this, encrypted documents may work in interactive Copilot but not in grounding-based retrieval scenarios.

Please note that as of now there is no public timeline is available as this remains a product roadmap topic and updates will only be communicated through official documentation or release notes.

Please check if the following steps help-

1. Validating label configuration
   • Confirm use of user-defined permissions
   • Confirm encryption settings and EXTRACT rights
2. Performing a controlled test
   1. Select one affected document
   2. Test current configuration
   3. Modify:
      • Remove encryption temporarily, or
      • Apply SharePoint-permission-based / default label
   4. Re-run the same Retrieval API request
   Expected outcome: If the document appears after the change, the protection model is the contributing factor. Please note that changes to sensitivity labels may take some time to reflect in retrieval results as content is reprocessed.
3. Validating API and identity configuration
   1. Use delegated authentication
   2. Ensure:
      • Files.Read.All
      • Sites.Read.All
   3. Use natural language query
   4. Confirm dataSource: "sharePoint"
4. Validating Foundry grounding setup
   1. Ensure user identity passthrough (On-Behalf-Of)
   2. Avoid relying only on managed identity
5. Treat PAYG as secondary
   • PAYG propagation may take a few hours
   • Initial calls may behave inconsistently
   However, the immediate change after encryption strongly indicates the label configuration as the main factor.

The following references might be helpful , please check them out

• Microsoft 365 Copilot Retrieval API Overview | Microsoft Learn
• Use the Microsoft 365 Copilot Retrieval API to Retrieve Grounding Data | Microsoft Learn
• Microsoft 365 Copilot data protection architecture | Microsoft Learn
• Considerations for Microsoft Purview to manage Microsoft 365 Copilot and Channel Agent in Teams for security and compliance | Microsoft Learn
• Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn
• Use SharePoint content with agent API - Microsoft Foundry | Microsoft Learn
• Microsoft 365 Copilot Retrieval API pay-as-you-go consumption (preview) | Microsoft Learn
• Configure SharePoint with a sensitivity label to extend permissions to downloaded documents | Microsoft Learn
• Enable sensitivity labels for files in SharePoint and OneDrive | Microsoft Learn

Please let us know if the response was helpful

Thank you

Please "Accept" the answer with an "Upvote" if the response was helpful. This will be benefitting other community members who face the same issue.

Hello beguem,

Greetings! Thanks for raising this question in Q&A forum.

This is a very well-documented issue and you have done an excellent job of isolating it the fact that the standard Graph Search API returns results while the Retrieval API returns empty retrievalHits is the key clue here. Let me explain exactly why this happens and walk you through how to fix it.

The core reason is that the Retrieval API does not use the same index as the Graph Search API. The Graph Search API uses Microsoft Search (which indexes all content accessible to the user), while the Retrieval API uses the Microsoft 365 Copilot Semantic Index which is a separate, deeper AI-powered index that has its own sync schedule, file type restrictions, and propagation delays. Since your pay-as-you-go billing was activated only about 24 hours ago, the semantic index is very likely still syncing for your content.

Here is a step-by-step guide to diagnose and resolve this:

Step 1 — Wait for semantic index propagation to complete

This is the most likely cause given your 24-hour timeline. After pay-as-you-go or Copilot license activation, the semantic index can take anywhere from a few hours to 2–3 days to fully sync content from SharePoint.

There is nothing to configure here — simply re-test your Retrieval API call again after waiting a little longer. Many users report results start appearing after 48–72 hours of activation. If this is the issue, it will resolve itself.

Step 2 — Verify your SharePoint documents are of a supported file type

This is a very common but easy-to-miss cause of empty retrievalHits. The Retrieval API's semantic and hybrid retrieval only works with specific file types. Check that your SharePoint content falls into one of these supported formats:

• .docx or .doc
• .pptx
• .pdf
• .aspx (SharePoint pages)
• .one (OneNote)

If your files are .xlsx, .txt, .csv, or any other format, the Retrieval API may fall back to lexical retrieval only — which can still return empty results depending on the query. The Graph Search API, on the other hand, handles all file types, which is why it returns results where the Retrieval API does not.

Step 3 — Confirm the Foundry SharePoint tool is using user identity (not managed identity)

This is critical for the Foundry sharepoint_grounding_preview tool. Application-only tokens (such as those from the Foundry project managed identity) are explicitly not supported by the Retrieval API — it requires delegated user identity (identity passthrough).

• In your Foundry project configuration, verify that the SharePoint grounding tool is set to use user identity passthrough and not the project's managed identity.
• The Sites.Selected and application-level permissions you granted to the managed identity are correct for other scenarios but will not work for the Retrieval API specifically — it must run under the calling user's delegated token.

Step 4 — Check file sizes

Even if the file type is supported, files exceeding the following limits will be excluded from the semantic index:

• .docx, .pptx, .pdf — must be under 512 MB
• All other supported types — must be under 150 MB

If any of the SharePoint documents you are querying exceed these limits, they will simply not appear in retrievalHits even though they show in Graph Search.

Step 5 — Narrow the search scope in Foundry

For the Foundry SharePoint grounding tool specifically, try narrowing the search scope to a specific SharePoint site or document library rather than searching broadly. This reduces the search space, improves relevance scoring, and helps surface results sooner even when the semantic index is still syncing.

Step 6 — Double-check delegated permissions for the direct Retrieval API call

Your current setup looks correct for the direct Graph Explorer call, but confirm these delegated permissions are admin-consented on your app registration:

• Files.Read.All (delegated)
• Sites.Read.All (delegated)

Make sure you are authenticating in Graph Explorer as the licensed E5 + Copilot user and not as a service account or guest user, as the Retrieval API strictly enforces user identity.

Step 7 — If empty results persist after 72 hours, raise a support case

If after 2–3 days the Retrieval API still returns empty retrievalHits for confirmed .docx or .pdf files that are accessible to the calling user and under the size limit, this is likely a backend semantic index issue specific to your tenant. In that case:

• Go to the Microsoft 365 Admin Center or Azure Portal.
• Open a support request and include the following details: the Graph Search API returns results for the same query, Retrieval API returns HTTP 200 with empty hits, pay-as-you-go was activated on a specific date, and all documented permissions and file type requirements are met.

To summarise the most likely cause right now is simply the semantic index propagation delay after your recent pay-as-you-go activation. While you wait, verify your file types are in the supported list and make sure the Foundry tool uses user identity passthrough instead of the managed identity. These two checks together should resolve the issue for you.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.