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

Question

SUMMARY

The Microsoft 365 Copilot Retrieval API returns HTTP 200 with empty retrievalHits for SharePoint content that is confirmed to exist and be indexed in SharePoint search. The Microsoft Foundry SharePoint grounding tool (sharepoint_grounding_preview) also returns empty documents for the same queries.

CONFIGURATION

• M365 license: E5 + Microsoft 365 Copilot (assigned to calling user)
• Pay-as-you-go Retrieval API billing policy active for all users
• Permissions granted on calling user's app registration: Files.Read.All, Sites.Read.All (delegated, admin consented)
• Permissions granted on Foundry project managed identity: Files.Read.All, Sites.Read.All, Sites.Selected (application, admin consented)
• SharePoint site-level permissions granted to Foundry managed identity via Grant-PnPEntraIDAppSitePermission
• SharePoint and Foundry project are in the same Entra tenant

REPRODUCTION

Direct Retrieval API call via Graph Explorer, authenticated as licensed user:

POST https://graph.microsoft.com/v1.0/copilot/retrieval
Request Body:
{
	"queryString": "Schadenbearbeitung Kfz",
	"dataSource": "sharePoint"
}

Response: HTTP 200
{
	"retrievalHits": []
}

The same query via the standard Graph Search API (POST https://graph.microsoft.com/v1.0/search/query) returns the expected documents correctly, confirming the content exists and is accessible to the calling user.

ADDITIONAL CONTEXT

• Pay-as-you-go billing was activated approximately 24 hours ago
• The Retrieval API endpoint is reachable and returns 200
• The Foundry SharePoint grounding tool dependency trace in Application Insights shows the tool executing with a real duration (~2700ms) and returning {"documents": []}

Answer 1

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.

Answer 2

The behavior matches a scenario where prerequisites and permissions are correct, but the Retrieval API and Foundry SharePoint tool still return no hits because of indexing/semantic index limitations and current service constraints.

From the documented limitations and troubleshooting guidance, the following checks and constraints apply to this scenario:

1. Permissions and identity model
   • Retrieval API requires delegated permissions with user identity only:
     • Files.Read.All and Sites.Read.All for SharePoint/OneDrive.
     • Application permissions are not supported.
   • The SharePoint tool in Foundry also requires user identity (identity passthrough) and does not support application-only authentication (AppOnly OBO tokens not supported by target service).
   • For the direct Retrieval API call in Graph Explorer, the delegated Files.Read.All and Sites.Read.All permissions on the app registration align with the documented requirements.
   Implication for this setup:
   • The direct Graph Explorer call is correctly using delegated permissions.
   • For the Foundry SharePoint grounding tool, ensure the tool is configured to use user identity rather than the project managed identity; the documented behavior indicates app-only identities are not supported.
2. Licensing and pay-as-you-go
   • Retrieval API is available at no extra cost to users with a Microsoft 365 Copilot add-on license.
   • For non-Copilot-licensed users, pay-as-you-go is required and currently preview.
   • For the SharePoint tool in Foundry, non-Copilot users can use it via pay-as-you-go; for Copilot-licensed users, the license alone is sufficient.
   • A known error for missing license is Forbidden: Authorization Failed - User does not have valid license; this is not occurring here, indicating licensing is accepted.
   • There is a known propagation delay pattern: after license assignment, the Retrieval API can initially fail or misbehave and later start working once backend propagation completes.
   Given pay-as-you-go was activated ~24 hours ago and the call returns HTTP 200, licensing and billing activation are likely accepted, but there can still be backend propagation/semantic index sync delays.
3. Retrieval API vs. Graph Search API behavior
   • The Retrieval API is optimized for context recall and uses the Microsoft 365 Copilot semantic index.
   • It is subject to all limitations of the semantic index.
   • The Graph Search API (/search/query) uses Microsoft Search and can return documents even when the semantic index or Retrieval API constraints prevent results.
   Relevant limitations for this case:
   • Retrieval from SharePoint supports semantic and hybrid retrieval only for .doc, .docx, .pptx, .pdf, .aspx, .one file extensions. Other extensions use lexical retrieval only.
   • Retrieval from nontextual content (images, charts) is not supported.
   • Retrieval from text in tables is limited to .doc, .docx, .pptx.
   • Files larger than 512 MB for .docx, .pptx, .pdf and larger than 150 MB for other extensions are not supported.
   • If retrievalHits is empty, the service has determined no relevant results under these constraints.
   Therefore, it is possible for:
   • Graph Search to return documents (because they are indexed in Microsoft Search), while
   • Retrieval API returns empty retrievalHits because:
     • The files are of unsupported types for semantic retrieval, or
     • The relevant content is in unsupported structures (e.g., certain tables), or
     • The semantic index has not yet fully synced for those items.
4. Foundry SharePoint tool behavior
   • The SharePoint tool in Foundry uses the same underlying Retrieval API and semantic index.
   • Documented troubleshooting for the SharePoint tool lists:
     • Tool returns no results when the user lacks access to the SharePoint content.
     • Incomplete document retrieval when content is not indexed or when semantic index sync is delayed.
     • Inconsistent search results due to semantic index sync delay.
   Since Graph Search confirms access and indexing in Microsoft Search, the most relevant documented cause for empty results from the SharePoint tool is semantic index sync delay or content not yet available in the semantic index, even though it is in Microsoft Search.
5. Actionable checks and next steps based on documentation Within the documented constraints, the following steps are supported:
   1. Confirm identity model for Foundry SharePoint tool:
      • Ensure the tool is configured to use user identity (identity passthrough) rather than the Foundry project managed identity, as application-only tokens are not supported.
   2. Validate file types and sizes:
      • Check that the documents expected to be returned are of supported types for semantic/hybrid retrieval (.doc, .docx, .pptx, .pdf, .aspx, .one) and within the documented size limits.
      • If they are other types, Retrieval API will fall back to lexical retrieval, which may still return empty results depending on the query.
   3. Allow for semantic index and licensing propagation:
      • The documentation and Q&A evidence show that Retrieval API behavior can change after some hours once licensing and semantic index propagation complete.
      • Given pay-as-you-go and Copilot licensing were recently activated, re-test after additional time and verify whether results begin to appear.
   4. Narrow search scope and queries in Foundry:
      • For the SharePoint tool, narrow the search scope (specific sites/libraries) and use more specific queries to reduce search space and improve relevance.
   5. If the issue persists after propagation and file-type checks:
      • Given that the documented behavior includes known semantic index sync delays and that the API is in preview, open a support case with Microsoft, referencing that:
        • Graph Search returns the documents.
        • Retrieval API and Foundry SharePoint tool return empty results.
        • Licensing and delegated permissions meet the documented requirements.

---

References:

• Overview of the Microsoft 365 Copilot Retrieval API
• Use SharePoint tool with the agent API (preview) (rest)
• Use SharePoint tool with the agent API (preview) (typescript)
• Use SharePoint tool with the agent API (preview) (python)
• Use SharePoint tool with the agent API (preview) (csharp)
• Use SharePoint tool with the agent API (preview) (java)
• Retrieve grounding data (graph-preview)
• Microsoft 365 Copilot Retrieval API errors with Authorization Failed - User does not have valid license - Microsoft Q&A