Share via

Office.context.mailbox.item returns empty object when translateExchangeIds fails with 403c

Aniket Tripathi 0 Reputation points
2026-04-15T09:06:13.63+00:00

We're experiencing an intermittent issue in our Outlook add-in, ExtendSync for Outlook by CloudExtend.

We read the selected mail item via Office.context.mailbox.item, use convertToRestId() to get the REST ID, and call makeEwsRequestAsync() for additional properties.

Intermittently, Office.context.mailbox.item returns a degenerate object in compose mode — it's truthy but all properties (itemId, subject, from, to, body) are inaccessible and JSON.stringify() returns "{}". The OWA console shows POST translateExchangeIds failing with 403 (Forbidden) at the same time. The issue occurs on both OWA (outlook.office.com) and Outlook Desktop (Windows and Mac Version 16.101.3 ), persists across add-in reloads, and sometimes only resolves after fully restarting Outlook. We cannot reproduce it consistently in our development environment.

Questions:

(1) Does Office.js return a fallback empty object when translateExchangeIds fails internally?

(2) Will re-reading Office.context.mailbox.item after a delay return a hydrated item, or is the failed state cached until the next ItemChanged event?

(3) What's the recommended way to detect this degenerate state, given the object is truthy and itemId being undefined is valid in compose mode?

We're considering retrying the item read up to 3 times with a 1.5s delay. Is this viable?

Microsoft 365 and Office | Development | Office JavaScript API
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vergil-V 12,785 Reputation points Microsoft External Staff Moderator
    2026-04-15T13:04:40.5366667+00:00

    Hi @Aniket Tripathi   

    Based on my review of the available documentation and behavior described, I am happy to share the insights I have gathered so far regarding your questions. 

    Before continuing, I would like to clarify that Microsoft Q&A is a user-to-user support forum. Moderators and contributors, including Microsoft employees participating externally, are not able to intervene in product behavior or access internal systems. Our role is limited to sharing documented behavior, supported guidance, and practical insights based on experience. 

    1/ Does Office.js return a fallback empty object when translateExchangeIds fails internally? 

    Microsoft’s documentation does not describe any intentional fallback or placeholder object for this scenario. Typically, API failures are reported through errors in asynchronous callbacks. 

    However, the presence of a truthy but empty object, together with a 403 Forbidden error from the translateExchangeIds call in the console, indicates that the add‑in did not receive the expected data from the server. In compose mode, Office.context.mailbox.item acts mainly as a reference handle. If the background process that populates this handle does not complete successfully, the object may still exist but contain no usable properties. 

    2/ Will re-reading Office.context.mailbox.item after a delay return a hydrated item, or is the failed state cached until the next ItemChanged event? 

    Accessing Office.context.mailbox.item gives you a reference to the current message, but in compose mode most of its data is not available directly. Instead, properties such as the item ID or subject must be retrieved using asynchronous APIs like getItemIdAsync or subject.getAsync. 

    According to Microsoft documentation, whether these calls succeed can depend on the item’s current state and its synchronization progress. Each asynchronous call is a separate request to the Outlook system, so calling the same API again after a short delay is the supported way to check whether the item has become available or whether a temporary sync delay has cleared. 

    image Reference: Office.MessageCompose interface - Office Add-ins | Microsoft Learn 

    There is no documentation stating that a failed retrieval is permanently stored until the next ItemChanged event. For this reason, retrying asynchronous retrieval remains the recommended and supported approach when the initial call does not return the expected data. 

    3/ What's the recommended way to detect this degenerate state, given the object is truthy and itemId being undefined is valid in compose mode? 

    A robust approach is to use the asynchronous APIs and inspect their results as part of your item validation flow: 

    1. Use getItemIdAsync: In compose mode, call Office.context.mailbox.item.getItemIdAsync()  
    2. Examine the Status: Check if asyncResult.status === Office.AsyncResultStatus.Failed and examine asyncResult.error.code.  you should look for codes like ItemNotSaved to identify why the request did not succeed. 
    3. Validate Before Proceeding: Only after successfully retrieving a valid ID should you proceed to convertToRestId  

    Reference: 

    *Regarding your retry proposal: 

    Yes. As mentioned earlier, the item may require time to synchronize. Retrying the item retrieval up to three times, with approximately a 1.5 second delay between attempts, is a reasonable and supported approach. This aligns with Microsoft guidance on handling synchronization timing in cached scenarios and ItemNotSaved responses when calling getItemIdAsync. 

    I hope the information above provides some additional insight.  If you have any updates or have further details to share, please feel free to let me know. 

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.