Microsoft-graph-docs: [Feature Request] Return id after sending email

[Hongbo-Miao]

Right now after sending an email

POST https://graph.microsoft.com/v1.0/me/sendMail

Request Body:

{
  "message": {
    "subject": "hello",
    "body": {
      "contentType": "Text",
      "content": "hello world!"
    },
    "toRecipients": [
      {
        "emailAddress": {
          "address": "[email protected]"
        }
      }
    ]
  }
}

The response is null, it does not return any id for the mail.

Please at least return the basic info id to help developers easily control app states. Thanks

Reason: After sending the email, developers will save the email info in the app state. However, if the app fetches the emails including that one again, there is no easy way to know any of the emails is same with the email stored before in the app state, which will cause saving two emails in the app state.

[mngyuan]

I also have this ask, and I'll elaborate a little bit.

If you send an email using the /me/sendMail endpoint, you don't receive any information about the email. If your app needs to store the id, or any other information about the email, a JSON response would be better. For this reason the app I'm working on first POSTs to /me/messages to create a draft, saves the id from the response, and then POSTs to /me/messages/<id>/send.

If you could POST to /me/sendMail and just receive the same information back as POST to /me/messages, that'd be great

[Hongbo-Miao]

One alternative way I thought is saving in draft first and then send out. But the problem is even I save the mail in draft first, after sending, the mail id actually changed. So I cannot use this way neither.

[Hongbo-Miao]

Ok, the team is working on an ImmutableId, hopefully it will release soon.

[Hongbo-Miao]

Another better way is actually using open extension, you add a hidden id to the mail when you send out. When you get new mails, compare the hidden id. But I met the issue cannot return open extension when use delta.
I will close this now since using open extension is a better way.

[mngyuan]

@Hongbo-Miao, where did you see that the team is working on an immutable ID? if that's implemented soon it'll solve another issue I have where draft emails ids change when they are sent, so keeping track of when a draft email was sent is difficult

[Hongbo-Miao]

@phorust
Even if immutable ID released, you should still use open extension to add a hidden id to the mail in the draft, after you send mail, when you fetch mails again, you can compare that hidden id which won't change. Because this way is faster than waiting the id returns.

[Hongbo-Miao]

@phorust please wait the Immutable Id officially publish. Or if you are requesting as Microsoft customer, you should already get email and have early access of it.

[djnhh0an]

Dear @Hongbo-Miao : Could you please update status on this issue?

[Hongbo-Miao]

I am also waiting to use Immutable Id, but I can tell it is definitely not ready for production use. I cannot tell further info. If you need further info or want to be an early adaptor to test, please contact Outlook team (I am working in Excel team)

[kudeshiyah]

@Hongbo-Miao is there any work around this issue, i am facing the same issue. Please help.

[Hongbo-Miao]

I have left Microsoft. Reopen this and let current Microsoft people answer and close this issue later.

[lievenjanssen]

Current Microsoft people are you there? Looks like a 👻🏠 here!

[Apollinaire]

I have tried with the immutable Ids on both the /beta endpoint and the v1 endpoint:
POST on /me/messages to create a draft and get an immutable Id.
POST on /me/messages/{immutable-message-id}/send to send the mail
Wait a moment (10 seconds)
GET /me/messages/{immutable-message-id} -> 404 not found.
Both "immutable" ids are the same except for the last 4 characters:

from draft:         .....................................................LiCbgAAABDVagAA
in the sent folder: .....................................................LiCbgAAABDVbAAA

So that means we have Immutable Ids, but apparently when you send a draft the resource is deleted and a new one is created in the Sent folder. So the "immutable" ids are different.
I found a workaround to this: use the conversationId to find the sent message. If it's a new message you're creating, the conversationId field on the draft will (hopefully) be unique and won't change when you send the message. So then you can do:

GET /me/messages?$filter=conversationId eq '{conversationId-from-draft}'

That should return:

{
  @odata.context: 'whatever',
  value: [
    {
      id: messageId, // <- the correct 'sent' message Id
      ...all the rest from the message resource
    }
  ]
}

[AlmogBaku]

just set an internetMessageId when you create the message, the search for it /users/{{user}}/messages?$filter=internetMessageId eq '<c56b29ba-e5f9-4a38-bfab-9f6f47a86814@sth>'

[Apollinaire]

I agree that this is one of the workarounds. To avoid using a potentially useful field you can also use a personal extension I think. However, I think fixing the problem at the root is better than letting people find hacky workarounds to their poorly designed API.

[Misiu]

This would be super useful. Right now we must create drafts, then send it, that's two requests, with this feature implemented we would only have to do a single request.

[iflow]

See my workaround in this comment: https://github.com/microsoftgraph/microsoft-graph-docs/issues/6256#issuecomment-559440385

[msftbot[bot]]

This issue will be closed because we do not support feedback captured directly from github new issue page. Also, this issues list is not intended for service issues, questions, or service feedback.

To provide feedback on Microsoft Graph documentation, please scroll to the Feedback section at the bottom of the related documentation page. You can click This page and create new feedback there. This gives the team the necessary context of your feedback.

If you have service issues and want to raise a support request, and if one of the following applies:

• You are an administrator of an active Azure subscription - raise a new technical support ticket at the Azure Admin Center.
• You are an administrator of an Office 365 or Microsoft 365 tenant - raise a new service request using the Support menu in the Microsoft 365 Admin Center.

If you would like to ask a question about Microsoft Graph, please visit Stack Overflow and ask your questions there using the [microsoft-graph] tag.

If you have suggestions or feedback on Microsoft Graph, please submit this at Microsoft Graph Uservoice.