"message": "Invalid request", "source": "api.connectorp.svc.ms"

[ericsnell]

I'm trying to write an attachment from an email to OneDrive and it keeps erroring with 

{

  "status": 400,

  "message": "Invalid request",

  "source": "api.connectorp.svc.ms"

}

I found the other topic: https://powerusers.microsoft.com/t5/Using-Connectors/OneDrive-for-Business-Create-File-Invalid-Reque...

However the "fix" was to "not create a folder" 

And I'm not trying to create a folder, I'm just trying to create a file in OneDrive - the folder already exists.

Anyone have a fix for this?

Picture of the flow (super simple)

[Pstork1]

Can you show what you are using when you create the file in OneDrive?  The JSON for the file content should include $Content and $Content-Type.

[ericsnell]

  "$content-type": "application/octet-stream",

  "$content": "JVBERi0xLjQKJd/++LIKMSAwIG9iago8PC......

[Pstork1]

The $content-type value isn't always application/octet-stream.  There are specific content-types for different types of files.

[ericsnell]

These are currently all PDF files I’m trying to save from email so I can then take the next automated step- so I presume in this case the content type will be the same.  Does the content type have anything to do with the error? 

[ericsnell]

Or does the fact that I’m using my account to do this and there is MFA on it cause this? 

[Pstork1]

The error you are getting is because the $content-type isn't in the file contents you are using to create the file.  The file Contents field when creating a file should have both a $content-type value and a $content value.  In your flow you only have a $content value.

[ericsnell]

not sure I'm following because the result has both a content type and content : 

"$content-type": "application/octet-stream",

  "$content": "JVBERi0xLjQKJd/++LIKMSAwIG9iago8PC......

what am I not seeing?

[ericsnell · Accepted solution]

I found the problem - it was not related to the content or the content-type; the resolution was to use the 'picker' to select the file location instead of the 'shared link' to the folder location; this removed the protocol and some of the root path information and put it directly into onedrive -- I've only tested it once, so don't know if it'll keep running, but the file path value appears to have been the issue.