Graph API Move Message API intermittently failing for specific email messages

A 201 Created response means the move request succeeded and returns the new message resource. The move operation creates a new copy of the message in the destination folder and removes the original message. Because the moved item is a new message resource, the message identifier changes after the move.

For this scenario, verify these points:

1. Confirm the destination folder identifier is correct. The request body must include destinationId, which can be the destination folder ID or a well-known folder name.
2. Treat the response body as the source of truth after the move. Since the API creates a new copy in the destination folder, any logic that checks the original message ID in the target folder can appear as if the move failed.
3. If the app is moving from a custom folder such as Auto to another custom folder such as Manual, use the actual folder ID for Manual rather than assuming a display name will resolve.
4. Ensure the app has Mail.ReadWrite, which is the least-privileged permission listed for this API.
5. Capture and inspect the returned message object from the 201 Created response for the moved item, then use that new item identity for any follow-up processing.

Supported request pattern:

POST /me/messages/{id}/move
Content-Type: application/json

{
  "destinationId": "{manual-folder-id}"
}

If the app is using PowerShell, the equivalent pattern is:

$params = @{destinationId = "<manual-folder-id>"}
Move-MgUserMessage -UserId $userId -MessageId $messageId -BodyParameter $params

Key behavior relevant to the symptom:

• Success response: 201 Created
• Result: original message is removed, a new copy is created in the destination folder
• Implication: checking only the old message ID can make a successful move look like a failure

• message: move
• Move and copy email messages by using EWS in Exchange
• Move-MgUserMailFolderMessage