Microsoft-graph-docs: How do I create a message and then send it without losing the ID?

[vishaldpatel]

I'd like to create and send a message.
I'd like to:

• Create a message with an immutable ID.
• If I understand correctly, the only way to do this is to create a Draft first.
• Send that message without the ID changing.

According to the above documentation, if I create a Draft first, and then send it, then the ID may change.

That does not sound immutable to me in the most essential of use cases for me.

How do I:

• Create and send a message by API.
• Get notified by the API that the exact message that I created and sent is now in the Sent folder?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 77dc8516-103a-7df2-2685-1ce9045941b5
• Version Independent ID: 90ebf4ab-1563-4a6d-d184-c91159352366
• Content: Get immutable identifiers for Outlook resources - Microsoft Graph
• Content Source: concepts/outlook-immutable-id.md
• Product: outlook
• Technology: microsoft-graph
• GitHub Login: @angelgolfer-ms
• Microsoft Alias: MSGraphDocsVteam

[iflow]

Possible workaround:

1. Create draft message
2. Remember the _internetMessageId_ property of the draft message
3. Send the message
4. Wait some seconds - yes really, that's the awkward step... Since we do not know when the message gets actually sent. Most of the time a basic message without attachments should be sent within 1-2 seconds.
5. Search the sent message with the _internetMessageId_ property https://graph.microsoft.com/v1.0/me/messages?$filter=internetMessageId eq '<VI1PR0602....2.eurprd06.prod.outlook.com>'
6. You should receive the message object of the sent message. Relax! OR: You would againg receive the draft message if it haven't been sent yet. You can check it via the _isDraft_ property.

As an alternative to immediately searching the sent message you could do it with a cron job and check for sent messages every X minutes.

[Misiu]

@iflow thanks for workaround.
Have you tried immutable id (https://docs.microsoft.com/en-us/graph/outlook-immutable-id)?
This way you should be able to use "standard" id instead of internetMessageId

[vishaldpatel]

@Misiu - one thing to keep in mind when using the immutable ID is that depending on your use-case, it is not immutable. For example, if the user sends a draft message, then the immutable ID of the copy in Sent Items will not be the same immutable ID of the draft message.

[Misiu]

@vishaldpatel isn't that the whole point of immutable ID? The message is moved to send folder, so it should have the same id.
I'll check that and get back here with the results

[Misiu]

@vishaldpatel I just checked that.
I've created a draft, added a couple of attachments and send that mail.
After it got delivered I searched for an email with same id and it was in Send folder.
So from my tests, it looks like Immutable Id works as expected.

Can someone confirm this?

[vishaldpatel]

@Misiu - things may have changes sing I last authored my comment. It would be more useful if someone from the MS Graph / Exchange team would confirm it.

The documentation here: https://docs.microsoft.com/en-us/graph/outlook-immutable-id, under "Lifetime of Immutable IDs" is still the same as before.

[Misiu]

@vishaldpatel this is very confusing.
I'm creating a draft using:

var email = new Beta.Message
{
    Body = new Beta.ItemBody
    {
        Content = "Works fine!" ,
        ContentType = Beta.BodyType.Html,
    },
    Subject = "Test",
    ToRecipients = recipientList,
};

Beta.Message draft = await graphClient.Users["[email protected]"]
.MailFolders.Drafts.Messages.Request()
.WithImmutableId().WithMaxRetry(5)
.AddAsync(email);

and then I send that draft using:

await graphClient.Users["[email protected]"].Messages[draft.Id] .Send().Request() .WithImmutableId().WithMaxRetry(5) .PostAsync();

I use WithImmutableId in two places, maybe that's the key.

Here is extension method I'm using:

public static class GraphExtensions
{
    public static T WithImmutableId<T>(this T baseRequest) where T : IBaseRequest
    {
        baseRequest.Headers.Add(new HeaderOption("Prefer", "IdType=\"ImmutableId\""));
        return baseRequest;
    }
}

Could you check that behavior in your code?

[vishaldpatel]

@Misiu - no can do.. our systems rely on API documentation being the canonical source of truth, since the code working a certain way could be more a bug than a feature.

[jasonjoh]

@vishaldpatel @Misiu I reproduce the behavior Misiu is seeing. This is great if it's intended!!

@svpsiva can you confirm this is an intended change? ImmutableId carries over from draft to copy in sent items?

[Misiu]

@jasonjoh @svpsiva @vishaldpatel please note I've used my extension method when creating a draft and when sending that draft. Maybe this is the key?
I really hope this is an intended feature, not a bug.
If this is by design please update the docs.

[jasonjoh]

@Misiu that's my plan, just want to confirm first. It didn't use to work this way when I originally wrote this doc.

[Misiu]

@jasonjoh I'll keep my fingers crossed this is a feature, not a bug :)

[wulymammoth]

I just made several attempts to see if this works from Graph Explorer and it fails:

1. I used the boilerplate request body within Explorer hitting this endpoint: https://graph.microsoft.com/v1.0/me/sendMail, and sent myself a message and included under the request headers tab, the Prefer header with the value of: IdType="ImmutableId"

I received the following in the response headers:

cache-control: private
client-request-id: 7c69b6e5-05f7-4c8a-b7eb-7ca95dd012f4
content-length: 0
content-type: text/plain
preference-applied: IdType=ImmutableId
request-id: 7c69b6e5-05f7-4c8a-b7eb-7ca95dd012f4

Note: it appears that the immutable ID preference had been applied

1. I query for my messages and obtain the resource/message ID using this endpoint (no additional headers set aside from the default content-type): https://graph.microsoft.com/v1.0/me/messages. I look at the values key in the response and the first object's "id" key and copy it

2. I query for this particular message using the same endpoint: https://graph.microsoft.com/v1.0/me/messages/<message ID>, by passing the ID that I had just copied to ensure that the message exists/retrievable and it is

3. I go to my Outlook web client and move this message from Inbox into a custom folder, I've created, called "TESTING".

4. I again repeat the query in step 3 and receive a 404, ErrorItemNotFound

Can someone explain to me what's going on here?

[Misiu]

@sudostack I'm not sure about Graph Explorer and Outlook Web Client.
Try to do the following steps:
-create a DRAFT, add IdType="ImmutableId" to request header.
-send that draft (I also added the same header, not sure if this is required)
-search for that mail, it should be in the sent folder, search by the id of course.

I'm going to check if moving messages to a different folder changes the id (that should be immutable).

[wulymammoth]

@Misiu that worked! If I create a draft, send it, and move the message to a new folder, the folder identifier updates, and the message ID remains unchanged

However, it is not available when I do the same with /v1.0/me/sendMail endpoint. I don't understand why. My only guess is that endpoints that don't fall under the "messages" (/messages) resource and does not consider the immutable ID header at all -- may be an oversight

The process of drafting, then sending, incurs an additional round-trip. Can someone from Microsoft let us know whether immutable IDs would be made available to /me/sendMail? If not, I'm going to just work with the /messages resource and endpoint with the additional round-trip

[jasonjoh]

@sudostack when you POST to /me/sendmail, there is no ID returned because the response is just a 202 Accepted with no body. The two-step process of creating a draft and then sending allows you to get an ID from the draft, which then can be used to find the message in Sent Items.

[wulymammoth]

@jasonjoh ah! Good point - it's an async operation. I forgot. Thanks for clarifying 👍

[jasonjoh]

Sorry for the long delay in getting back here, but I can confirm this is an intended change. Immutable ID on a draft message should persist to the copy that ends up in Sent Items. I'll be updating the docs today.

[Misiu]

@jasonjoh finally I can remove extended properties. Thank you for confirming this behavior 🙂