Table of Contents
Exchange Admin API Fills Gaps Left by EWS

As you probably know, Microsoft will retire Exchange Web Services (EWS) from Exchange Online in October 2026. With less than a year to go , Microsoft 365 tenants should have a solid grasp of how EWS is used by apps. Hopefully, hybrid tenants have deployed the dedicated hybrid app to facilitate sharing of information like free/busy data, and an inventory of apps is being worked through to arrange for app retirement, app replacement, or code upgrades to eliminate EWS.
If you’re involved in overhauling EWS code, you’ve probably using the Microsoft Graph APIs to replace EWS calls, and have discovered some of the issues documented by Glen Scales in a recent article. The simple fact is that the Graph APIs do not cover every function available in EWS, and that’s the hole Microsoft plans to plug with the Exchange Admin API, launched in public preview on November 17.
A REST-based Cmdlet-Style API
According to Microsoft, the Exchange Admin API is a “REST based, cmdlet style administrative surface specifically designed to help organizations migrate away from EWS for specific Exchange admin scenarios and modernize automation workflows over HTTP.”
Peeling everything away, we discover that the Exchange Admin API is not a full-fledged REST API for Exchange Online management. Instead, it is a short-term fix to help customers to move away from EWS by providing an API that supports a limited set of scenarios that aren’t currently covered by a Graph API. The Exchange Admin API works by allowing applications to run Exchange Online cmdlets and receive the output from those cmdlets for processing. In essence, the API delivers a wrapper around selected Exchange PowerShell cmdlets. Although this might seem odd, giving apps the ability to run Exchange cmdlets is a pragmatic method that avoids recreating any wheels to deliver for what is essentially a discardable API.
Like apps that use Graph APIs to access tenant information, apps that use the Exchange Admin API must be authorized (be able to secure an access token) and possess a role (like the Exchange administrator) role to access Exchange data. Once authorized, apps can send POST requests to endpoints for processing.
Six Endpoints for the Exchange Admin API
The Exchange Admin API Public Preview includes six endpoints. The endpoints are:
- OrganizationConfig: Access tenant-wide MailTips related configuration.
- AcceptedDomain: Accepted domains and core domain settings for the tenant. The same information can be accessed using the List Domains Graph API (and the Get-MgDomain cmdlet from the Microsoft Graph PowerShell SDK).
- Mailbox: Read mailbox properties and manage Send on behalf delegates (view/update). Send on behalf delegates can also be managed with the Set-Mailbox cmdlet.
- MailboxFolderPermission: List, grant, modify, and remove folder level permissions (Inbox, Calendar, subfolders). This is equivalent to the Set-MailboxFolderPermission cmdlet.
- DistributionGroupMember: Retrieve membership for distribution groups. This is equivalent to the Get-DistributionGroupMember cmdlet.
- DynamicDistributionGroupMember: Retrieve membership for dynamic distribution groups. This is equivalent to running the Get-DynamicDistributionGroupMember cmdlet.
It might seem strange for the Exchange Admin API to include endpoints when other methods exist in terms of Graph APIs or PowerShell cmdlets. However, EWS is predominantly an interface used by email clients and applications rather than a platform for the automation of administrative operations like Exchange Online PowerShell.
Most of EWS code can be migrated to Graph APIs. The Exchange Admin API fills in the current gaps in Graph coverage to allow the developers of EWS applications to migrate their code to a newer platform in a way that maintains functionality, and that’s where the value of the API lies.
No Long-Term Future for the Exchange Admin API
Over the long term, Microsoft’s focus for automation of Exchange management tasks remains the Exchange Online management PowerShell module. For programmatic access, the focus is on Graph APIs, and highly functional APIs are available to access mailboxes, calendars, and other Exchange data.
It’s clear that the Exchange Admin API has not much of a future after the need to migrate EWS applications passes. Over time, Microsoft engineering effort will go into developing and expanding the capabilities of the Graph APIs. Once the gaps filled by the Exchange Admin API are addressed in Graph APIs, the reason for having the Exchange Admin API disappears.
For that reason, developers should continue to focus on writing code that leverages the Graph APIs with as little use of the Exchange Admin API as possible to avoid code that must eventually be replaced. Apps that move from EWS to the Exchange Admin API face going through two separate code migrations. We don’t know when the second migration will happen because Microsoft hasn’t given a date for when they will close the EWS gaps in the Graph APIs. In the interim, using the Exchange Admin API is a necessary sin to meet the EWS deprecation deadline in October 2026.
Documentation, including request patterns, and details of how to connect to the Exchange Admin API endpoints is available as an overview of the Exchange Admin API, getting started guide, and endpoint references.
Time for Testing
The Exchange Admin API is a preview. Those with responsibility for EWS applications are already on a tight schedule to get their code ready and tested before Microsoft removes EWS from Exchange Online in October 2026. If you’re in that situation, you should review and test the Exchange Admin API to determine if it’s needed, does the job for your application, and if not, provide feedback to Microsoft so that they can make changes before general availability. There’s no point in complaining if you don’t test the API!
Learn about managing Exchange Online and the rest of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.
Links to MS Documentation are 404.
Yep. The links seemed OK but I redid them and now they work.