Download Sharepoint and OneDrive files from MS Graph API returning Error 400

Edwin Fajar 146 Reputation points
2021-07-05T10:42:30.237+00:00

Previously, I have no problem when downloading Sharepoint and OneDrive files from MS Graph API using this endpoint Download the contents of a DriveItem. But since the 3rd of July 2021, I got Error 400 when downloading the file.

I tried to hit these endpoints using Application Permission and have Files.ReadWrite.All roles

GET /sites/{siteId}/drive/items/{item-id}/content
GET /users/{userId}/drive/items/{item-id}/content

And also tried to make a request directly to the URL from @microsoft.graph.downloadUrl property and got the same Error 400 result with this body.

{  
  "error": {  
    "code": "invalidRequest",  
    "innerError": {  
      "code": "badArgument"  
    },  
    "message": "One of the provided arguments is not acceptable."  
  }  
}  

I also see something strange from the response header at docID value. Usually, it has our site id value, but this one has value like this. The 00000000-0000-0000-0000-000000000000 seems like a dummy value.

XXXXX-my.sharepoint.com_00000000-0000-0000-0000-000000000000_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Any idea what is the cause? Is there any bug? Or I should add more property to the header?
Thanks

Microsoft Graph Files API
Microsoft Graph Files API
A Microsoft API to create an app that connects with files across OneDrive, OneDrive for Business, and SharePoint document libraries.
348 questions
SharePoint Development
SharePoint Development
SharePoint: A group of Microsoft Products and technologies used for sharing and managing content, knowledge, and applications.Development: The process of researching, productizing, and refining new or existing technologies.
1,969 questions
0 comments No comments
{count} votes

Accepted answer
  1. Edwin Fajar 146 Reputation points
    2021-07-07T02:09:39.45+00:00

    Hi @Michael ,

    Like @Andriejus said, we have another tenant where the download file works and there are several tenants that also didn't works.
    But I just check again this morning and now the download file works. I will check again for another tenant that has the same issue before.

    Thank you for your reply.


5 additional answers

Sort by: Newest
  1. Cathleen Raschke 11 Reputation points
    2021-07-06T16:21:59.193+00:00

    Having the same problem when using @microsoft.graph.downloadUrl property on our production tenant.
    It worked up until the last few days and it still works on our test tenant.

    2 people found this answer helpful.
    0 comments No comments

  2. Michael 17,921 Reputation points
    2021-07-06T08:21:24.07+00:00

    Hi @Edwin Fajar ,

    Just did a test on my tenant. The endpoint to Download file works on my end. Also I could download the file with the URL from @microsoft.graph.downloadUrl property.

    Let me check more about this issue.

    1 person found this answer helpful.

  3. Andriejus 61 Reputation points
    2021-07-06T07:49:16.227+00:00

    We have another tenant where download link returned by /content endpoint works. I tried comparing tokens received by endpoint where it works and one where it does not but besides values unique for that request, the tokens are the same.
    Like @Tommy Thorsen mentioned, removing tempauth query parameter does allow downloading files. This is not a solution though.

    4 people found this answer helpful.
    0 comments No comments

  4. Tommy Thorsen 21 Reputation points
    2021-07-05T20:39:55.283+00:00

    I have the same problem. It appeared around the same time as OP describes.

    If I grab the downloadUrl, and paste it into my browser's url bar, I get the same error message. However, if I first strip out the tempauth parameter from the downloadUrl, the download succeeds (since I am logged into sharepoint in my browser, and don't strictly need the url auth).

    This might indicate either a problem with generating or with parsing the JWT payload used for the tempauth parameter.

    4 people found this answer helpful.
    0 comments No comments