OneDrive app-folder content GET returns 400, but item-ID download succeeds

Question

OneDrive app-folder content GET returns 400, but item-ID download succeeds

Timo 51

A previously working GET /v1.0/me/drive/special/approot:/{path}:/content request now returns 400 invalidRequest. Microsoft’s documentation lists this download pattern as supported.

With the same token, both the app-folder and file metadata requests return 200. Downloading the same file by item ID, or by a path relative to the app-folder ID, returns the expected 302. This appears specific to the special/approot path-based content route. Could the OneDrive/Graph team investigate?

[moderator's note: PII removed]

0 comments

1 answer

Your answer

Answer 1

Vikki-T 11,350 Microsoft External Staff Moderator

For your privacy and security, I have covered the personal information included in your post. Please avoid sharing any personal or sensitive information publicly, such as serial numbers, order details, email addresses, phone numbers, or case-related information.

Hi Timo,

Thank you for providing the comparison results and the Request ID.

To help narrow it down, could you please confirm:

Whether this occurs with OneDrive Personal or OneDrive for Business.
Whether every file under the app folder is affected, including a newly created file with a simple name.
Whether the path contains spaces or reserved characters, and whether each path segment is properly percent-encoded.
The complete JSON response body returned with the 400 invalidRequest, with any access token or sensitive account information removed.
Whether the same request can be reproduced in Microsoft Graph Explorer.

As a temporary workaround, continuing to download the file by item ID, or by using a path relative to the app-folder item ID, would be reasonable since those methods are currently returning the expected redirect.

Please do not post the access token, full tenant details, or unredacted account information in this public thread. While my initial response may not fully resolve the issue, I truly appreciate your cooperation as we work together toward identifying the most effective solution. Thank you so much for your understanding.

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.

Timo 51 Reputation points

2026-09-25T11:24:42.3733333+00:00
Thanks for following up. Here are the results:

Account type: Reproduced with OneDrive Personal. OneDrive for Business has not been tested.

Files affected: Both an existing file and a newly created file named data_v4.wh return 400 invalidRequestthrough the app-folder path download route. I have not tested every file.

Path encoding: One captured request was GET /v1.0/me/drive/special/approot:/v4_Media/<file-id>:/content. Its path segments contain no spaces or reserved characters requiring percent-encoding. Neither does data_v4.wh.

Graph Explorer: Not tested. It would use its own app folder, so it would not test the same files.

The complete 400 response body, with request identifiers redacted, is:

{ "error": { "code": "invalidRequest", "message": "Invalid request", "innerError": { "date": "2026-09-25T11:13:59", "request-id": "[redacted]", "client-request-id": "[redacted]" } } }

As noted in my question, metadata requests and downloads by item ID succeed with the same token. This regression has caused sync failures for users of multiple applications. I have implemented workarounds, but the documented route still needs a service-side fix.

Could you confirm that this has reached OneDrive/Graph engineering and provide a tracking reference? I can share the unredacted request IDs privately.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Vikki-T 11,350 Reputation points Microsoft External Staff Moderator

2026-09-26T10:06:51.3633333+00:00
Hi Timo,

Thank you for providing such a thorough set of results.

I can understand your concern, especially since the behavior is affecting synchronization across multiple applications and you have already had to implement workarounds.

I want to be transparent that Microsoft Q&A moderators and community contributors cannot access the OneDrive or Microsoft Graph backend, submit an engineering investigation on a customer’s behalf, or generate an internal tracking reference from a forum thread.

To have the unredacted Request IDs reviewed privately and obtain a support case number, please use the official Microsoft Graph Support page and select the support route available for your account. When submitting the case, include:

That the issue is reproducible with OneDrive Personal.

The affected special/approot endpoint pattern.

The sanitized 400 invalidRequest response.

The UTC timestamps and unredacted Request IDs through the private support channel.

The successful metadata and item-ID download results using the same token.

The impact on synchronization across the affected applications.

Please continue using the item-ID-based method as the temporary workaround. Also, please do not post the unredacted Request IDs, access token, client secret, or account identifiers in this public thread.

Thank you again for documenting the behavior so carefully. The comparison you provided should help the appropriate support team distinguish this from a normal permissions or path-formatting problem.
Timo 51 Reputation points

2026-09-26T11:34:47.9333333+00:00

Thanks for your response. I retested today, and the /content request is working again with OneDrive Personal. It no longer returns 400 invalidRequest.

I haven’t changed the request and haven’t received a root-cause or fix confirmation, so I can say that the endpoint has recovered, but cannot confirm whether the underlying issue is permanently fixed. Microsoft support investigated intermittent invalidRequest failures on this same route earlier this year.
Vikki-T 11,350 Reputation points Microsoft External Staff Moderator

2026-09-29T10:43:17.3633333+00:00

Hi Timo,

Thank you for retesting and providing the update. It is good to hear that the /content request is working again with OneDrive Personal.

As no request changes were made and no root-cause or fix confirmation has been provided, it is reasonable to treat this as a recovery rather than confirmation of a permanent fix. Please keep the item-ID workaround and the relevant Request IDs available in case the issue recurs.

Thank you again for documenting the results so carefully.