We’d like to inform you about an update to how inline image attachments are handled when they’re programmatically added to a mail item’s signature or body in Outlook on the web and the new Outlook for Windows. This change may impact your add–in if it relies on the Exchange Web Services (EWS) ID that’s returned when adding inline images.

What’s changing?

Previously, when inline images were added to a mail item’s signature or body using the addFileAttachmentFromBase64Async/addFileAttachmentAsync method (Message Compose) with isInline set to true, the images were uploaded to the server before the call completed. An EWS ID was then returned in the callback function for each image (for example, AAkALgAAAAAAHYQDEapmEc2byACqAC/EWg0AW4xUByFbp0CroCNphMYEEAAGhqU3LwAAARIAEACS5VsVp3akQa7/BahqVbve). 

Going forward, inline images will be uploaded to the server after the addFileAttachmentFromBase64Async/addFileAttachmentAsync call completes and the images are added to a signature or body. Because the addFileAttachmentFromBase64Async/addFileAttachmentAsync call completes immediately without a network call, a temporary attachment ID is generated locally instead of an EWS ID. The attachment ID is prefixed with “addinId” (for example, addinId:31c91015-920a-6fed-f663-970a0f9bc5cd). The locally generated attachment ID is only temporary because an EWS ID is eventually generated for the attachment once it’s been uploaded to the server. 

The temporary attachment ID is fully supported with other attachment APIs, such as getAttachmentsAsync and getAttachmentContentAsync, for the duration of the current compose session (that is, while the mail item being composed is open). This behavior applies even after the attachments have been uploaded and assigned an EWS ID. Once the compose session ends, the temporary ID can no longer be used. 

Similar to the previous approach, users won’t be able to send the mail item until all inline attachments have been uploaded to the server. If a user attempts to send a message while attachments are still being uploaded, a dialog is shown informing them that the upload is still in progress. 

How does this change affect the getAttachmentsAsync call?

When you call the getAttachmentsAsync method in message compose mode after programmatically inserting inline attachments, the attachment ID returned in the callback function varies depending on whether the attachments have been uploaded to the server. 

• If the attachments are still being uploaded to the server, the getAttachmentsAsync method returns the temporary attachment ID in the id property. Additionally, it also includes a new property, isServiceAccessible, set to false. The isServiceAccessible property indicates whether the attachment ID can be used in other services, such as Microsoft Graph. The following is an example of an AttachmentDetailsCompose object returned when attachments are still being uploaded. 
  {"id":"addinId:31c91015-920a-6fed-f663-970a0f9bc5cd”,"name":"taskpane.jpg","contentType":"image/png","size":1318,"attachmentType":"file","isInline":true,"isServiceAccessible":false} 
• If the attachments have been uploaded to the server, the getAttachmentsAsync method returns the EWS ID in the id property and isServiceAccessible is set to true. The following is an example of an AttachmentDetailsCompose object returned when attachments have been uploaded. {"id":"AAkALgAAAAAAHYQDEapmEc2byACqAC/EWg0AW4xUByFbp0CroCNphMYEEAAGhqU3LwAAARIAEACS5VsVp3akQa7/BahqVbve","name":"taskpane.jpg","contentType":"image/png","size":1318,"attachmentType":"file","isInline":true,"isServiceAccessible":true} 

Where is it changing? 

The updated approach improves signature scenarios by making the addition of inline attachments fast and resilient. It avoids waiting on network uploads before the signature can be applied and it ensures that a transient upload issue doesn’t prevent the signature from appearing.

• Faster signature stamping (lower perceived latency). The signature can be set immediately, without waiting for each inline image to upload sequentially, so users see their signature sooner. 
• More reliable outcomes. A failure to upload any one inline image no longer causes the entire signature stamping operation to fail, so users still get a signature and can continue composing and sending. 

Action required 

If your Outlook add-in relies on the EWS ID of an attachment to make Microsoft Graph calls, you must adjust your code to ensure that the isServiceAccessible property returns true before making the Graph calls. 

If your Outlook signature add-in calls addFileAttachmentFromBase64Async/addFileAttachmentAsynctogether with setSignatureAsync, no changes are needed. 

Timeline 

Starting March 30, 2026, the changes to how inline attachments are handled will begin rolling out to production users. If needed, please make the necessary changes to your add-in before then.