title: Replacement for Outlook REST API used by office-js add-in
body: <p>I've an Outlook add-in written against office-js that uses the Outlook REST API to perform some operations that office-js cannot e.g. moving an email to another folder. This API is set to be decommissioned next year so I'm trying to find a suitable replacement.</p>
  <blockquote>
  <p>Version 2.0 of the Outlook REST API is deprecated.</p>
  <p>As announced on November 17, 2020, version 2.0 of the Outlook REST API has been deprecated. The v2.0 REST endpoint will be fully decommissioned in November 2022, and the v2.0 documentation will be removed shortly afterwards. Migrate existing apps to use Microsoft Graph. See a comparison to start your migration.</p>
  </blockquote>
  <ul>
  <li><a href="https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/use-outlook-rest-api" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/use-outlook-rest-api</a></li>
  </ul>
  <p>The notice above suggests moving to MS Graph however it is more complicated than the simple integration to use the REST API. With REST API I just needed to deploy the add-in to users and it would work, with requests to the API being performed client-side using a token obtained from getCallbackTokenAsync method of office-js. Graph seems to <strong>require</strong>  registering a service with the 365 admin account, adding more complexity to the install. Also Graph is not supported with on-premise Exchange and while the REST API doesn't look to be officially supported either it DOES work with on-premise Exchange 2016 and 2019.</p>
  <p>What would be the best replacement to use in my add-in given the following criteria?</p>
  <ul>
  <li>Use of API should be wholly via client-side JavaScript i.e. no proxying API calls through a server application for the add-in.</li>
  <li>Needs to work with O365, Exchange 2016, Exchange 2019 user environments. Client side should support Outlook desktop, OWA and Outlook for Mobile.</li>
  <li>Functionality wise the replacement API should be able to obtain details about selected email, move an email, create and send emails.</li>
  <li>Preference is for same install experience as today where only step is that the XML manifest needs to be uploaded.</li>
  <li>Process of using the API should not require interaction from end-user e.g. EWS and REST both can retrieve tokens for use with APIs today rather than forcing user to authenticate via a pop-up.</li>
  </ul>
  <p>Thus far EWS seems the closest match as it has the same simple deployment to users as REST, no need for a separate service to handle API calls and supports on-premise. However I'm worried it's likely to also become decommissioned going forward and also it lacks mobile platform support.</p>