Forum Discussion
sharedWithMe returns only one item
This is a known and subtle behavior difference between delegated (user) tokens and application-only tokens in Microsoft Graph, and it explains exactly what you’re seeing.
Short answer…
/drive/sharedWithMe does not fully work with application (client credentials) tokens.
It is designed to return items shared with the signed-in user, and only delegated user context is fully supported.
Graph Explorer uses delegated permissions, while your standalone app is using application permissions → hence only one item (or an incomplete set) is returned.
Your permissions are correct
Your request is valid
The endpoint is not supported for application-only tokens
This is expected behavior, not a bug.
Final recommendation
If your scenario is user-centric (which sharedWithMe is):
Switch to delegated authentication
My answers are voluntary and without guarantee!
Hope this will help you
Thank you for your reply.
However, I'm already using the delegated authentication. The request runs against https://graph.microsoft.com/v1.0/me/drive/sharedwithMe endpoint. According to the documentation: "Endpoints and APIs with the /me alias operate on the signed-in user only and are therefore called in delegated access scenarios."
My application requests user authorization via OAuth2 code grant flow.
Or, maybe I'm missing something here?
- NikolinoDEJan 13, 2026Platinum Contributor
You’re not missing something obvious in terms of auth flow — your reasoning about delegated auth and /me is correct. The missing piece is pagination, combined with a subtle Graph Explorer behavior.
/me/drive/sharedWithMe is a paged endpoint.
In your application response, you only see the first page, which in your case happens to contain one item.
In Graph Explorer, you see all items because:
- Graph Explorer automatically follows @odata.nextLink
- Your app does not, so it stops after the first page
This is why:
- Same user
- Same endpoint
- Same permissions
- Different results
Why you didn’t notice pagination
Your app response:
{
"@odata.context": "...",
"value": [
{ ... one item ... }
]
}
But Graph will only include @odata.nextLink when there is another page. Many SDKs and tools (including Graph Explorer) fetch it automatically, but raw HTTP clients do not.
If you inspect the raw HTTP response headers or enable tracing, you should see something like:
"@odata.nextLink": "https://graph.microsoft.com/v1.0/me/drive/sharedWithMe?$skiptoken=..."
Your app needs to explicitly follow that link.
Why Graph Explorer looks “complete”
Graph Explorer:
- Uses delegated auth
- Uses /me
- Automatically:
- Detects @odata.nextLink
- Fetches subsequent pages
- Merges results into one array
So it appears like a single response.
How to fix it in your app
Option 1: Follow @odata.nextLink (recommended)
Pseudo-logic:
GET /me/drive/sharedWithMe
while (@odata.nextLink exists):
GET @odata.nextLink
append items
Option 2: Increase page size
You can request more items per page:
GET /me/drive/sharedWithMe?$top=50
This reduces paging but does not eliminate it — you still must handle @odata.nextLink.
Important clarifications (to rule out other theories)
You are using delegated auth
/me/drive/sharedWithMe is correct
OAuth2 authorization code flow is correct
This is not an application-permissions limitation
This is not a OneDrive personal vs business issue
This is not a permissions scope issueFinal takeaway
The endpoint is working correctly.
Your app is only processing the first page of results.Once you implement pagination handling, your standalone app will return the same items as Graph Explorer.
- josuegomesJan 14, 2026Copper Contributor
Update: I got a reply from a Microsoft representative. It reads as follows:
"We recently discovered unexpected calling patterns to several of our APIs impacting our service quality for which we took expedited measures to mitigate. This mitigation reduced the set of returned results to 1 for the shared with me and recent APIs, impacting customer applications. Customers are advised to move away from use of these APIs. These APIs have been marked as deprecated.[...]
Unfortunately, we don’t have another straightforward way to retrieve that same information." - josuegomesJan 14, 2026Copper Contributor
Again, thank you for your reply.