Graph API '/me/drive/sharedWithMe' endpoint returns just one item.

I am also seeing the same behavior. For my team, we are receiving just "one result" returned from a cdata connector that uses API to show the "SharedDocuments" folder. This aligns exactly with the date others started experiencing this. Looks like it's a Microsoft server issue, and not client-side.

I'm experiencing the same issue for the last 2 weeks or so. This involves only receiving 1 "Shared documents" result from the API. We are using the cdata excel online connector and their support said no changes were made to the connector, and it is definitely a microsoft issue with the API returning only 1 result for "shared documents". They were able to verify this in the logs. Hopefully Microsoft takes this issue seriously as it's a huge blocker for my organization.

Similar/same issues: This was working fine until Wednesday/Thursday of last week. 11/6, 11/7/2025

We attempted to add Sites.[...] to the scope since the files in question are SharePoint based (though this was working fine, we thought an update may have been made to make files specific to oneDrive) After much reading it seems the Files.[...]were intended to be specific to OneDrive while Sites.[..] was intended to be SharePoint Drives; but all along we could see SharePoint files since we implemented over a year ago. however adding [sites] to the scope didn't help.

The application using the Graph API does yet show 1 file from SharePoint. We used the same account in the developer tools to query directly and we received 1 file a .png vs the application we use is set to only query for .xlsx or .xls so only one file came back there as well for a .xlsx.

In an unchanged application's environment yet using just [Files].[x] we see 1 file as well. So adding scope of Sites didn't address the problem if the intent was for Files to be just OneDrive, and sites to be just SharePoint.

This is negatively impacting our applications ability to use automation since the users are no longer able to access/browse more than one file on SharePoint sites. Existing automations continues to work fine. If I had to guess since the file/path is already known it's able to directly access the file without the overhead of browsing folders/files. However setting up a new write, or pulling data from a new file is no longer possible. This means we can't really maintain existing connections, nor can we add new ones.

I can also confirm, I am seeing only one shared document when querying the Shared Documents folder using the API. As this is more widespread, has support looked into this issue further?

Our additional testing shows the file which is displayed, at least when filtering for .xlsx, xlx is the one with the most recent date last modified. So the visible file changes depending on which file was last updated.

Has anyone opened an issue in the git library for this? https://github.com/microsoftgraph/msgraph-sdk-design I'm not seeing one... This appears to be a regression, breaking previously functional behavior. I understand it's deprecated; but I was under the impression stability existed until deprecation date November of 2027.

same here

Here the issue opened 2 weeks ago: https://github.com/microsoftgraph/msgraph-sdk-design/issues/120

Everything I've been reading on this says it is not going to be fixed. Yes the API is deprecated. and yes it still works but with degraded functionality. In order to move forward not all services are being continued some back office features were broke causing the API to lose functionality. One of those services is the "SharedWithMe". There were architecture issues involving security and complexity that are too insurmountable from an architecture and costs standpoint. As a result, certain features are limited / broken moving forward. Best option is to begin using the new libraries. Unfortunately for those using a 3rd party app; that means upgrading to a version using those new APIs... This is my understanding. Simply put: yeah it's broke. Move on.

Just where we stand I guess. seems like really bad notice/warning though. There'd be much more of an uproar if existing processes which already mapped to a specific object had broke as this would have broken workflows for many customers. As it stands "new" workflows are difficulty to create

"Best option is to begin using the new libraries." Ok, but which one?

I found that the search api returns also the shared documents/folders

https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview?view=graph-rest-1.0

I'll give a try

""Best option is to begin using the new libraries." Ok, but which one?"

Not libraries, functions sorry.

The basic flow is:

Find the site (SharePoint site or Teams-backed site) → get its site-ID

List all drives (document libraries) in that site → get drive-IDs

List contents of a drive or a folder → navigate, read, or download files

Example API calls

Assume you have a site URL like https://contoso.sharepoint.com/sites/ProjectX.

If the SharePoint site corresponds to a Microsoft Teams team, the same logic applies because Teams stores files in a SharePoint site/library behind the scenes.

Permissions

• For SharePoint libraries, your app usually needs Sites.Read.All (or Sites.ReadWrite.All if modifying) — not just OneDrive-scoped permissions.
• If using app-only (daemon) authentication, ensure you grant the permissions in Azure AD and consent tenant-wide. For delegated (user-context) flows, user consent + appropriate scopes must cover both /sites and /drives

Given the instability and deprecation of /sharedWithMe, I recommend rewriting your code to:

1. Discover sites (or know the site URL upfront)
2. Enumerate drives (/sites/{siteId}/drives)
3. Traverse folders/files via /drives/{driveId}/root/children (and then recursively if needed)

More on MSFT Graph Site: https://learn.microsoft.com/en-us/graph/

How to get "Shared with me" items from OneDrive using Microsoft Graph Search API (I cooked this solution with the help of GitHub Copilot)

The Problem

I needed to programmatically retrieve all folders shared with me from other users' OneDrive (the same list you see in the "Shared with me" view in the browser).

The obvious endpoint /me/drive/sharedWithMe only returned 1 item, while the browser showed 6 folders. This API seems unreliable for OneDrive for Business.

The Solution

Use the Microsoft Graph Search API with a KQL (Keyword Query Language) filter:

POST 
{
"requests": [{

    "entityTypes": ["driveItem"],

    "query": {

        "queryString": "isDocument:false AND path:\"<other-users-onedrive-base-path>\" AND -path:\"<my-onedrive-path>\""

    },

    "from": 0,

    "size": 500,

    "fields": ["name", "createdBy", "parentReference", "webUrl", "id"]

}]
}

KQL Query Breakdown

isDocument:false → Returns only folders, excludes files

path:"<base-path>" → Filters to only personal OneDrive items (e.g., https://contoso-my.sharepoint.com/personal/)

-path:"<my-path>" → Excludes items from my own OneDrive

Key Findings

/me/drive/sharedWithMe is unreliable for OneDrive for Business - it doesn't return all shared items

Search API works perfectly - returns all items that match the criteria

KQL path: filter works with URL prefixes - you can filter by the OneDrive base URL to get only personal OneDrive items (excluding SharePoint sites)

Deduplication may be needed - Search API can return duplicates, so filter by item ID

Authentication

I used MSAL with ROPC (Resource Owner Password Credentials) flow with a service account. The app registration needs Files.ReadWrite.All and Sites.Read.All permissions.

Result

Now I can retrieve exactly the same 6 folders that I see in the browser's "Shared with me" view!

HTH