EWS is officially on the clock, with retirement set for October 2026, and anyone still relying on it for those oddly specific but essential Exchange admin tasks can already feel the pressure building.
A lot of organizations have been in the same boat: EWS is old, PowerShell doesn’t fully replace some of the admin scenarios, and there hasn’t been a clean REST-based alternative until now.
That deadlock finally breaks now. Microsoft has finally announced the Public Preview of the Exchange Online Admin API, the modern, API-first admin layer.
Why Microsoft Introduced the Exchange Online Admin API
EWS has been around forever, and a lot of automation still depends on it. The challenge is that it was never built with modern cloud-first automation patterns in mind. It struggles with modern security needs, throttling behavior, governance expectations, and basically everything we expect from an API in 2025.
So Microsoft had to put a real alternative on the table, something modern, secure, and easier to integrate with today’s automation stack – the Exchange Online Admin API.
Now, before anyone assumes this is a magical all-in-one replacement:
- It’s not a full PowerShell substitute.
- It’s not a one-to-one rebuild of every EWS capability.
Instead, it’s a REST-based, cmdlet-style admin surface built specifically to plug the gaps that PowerShell doesn’t cover and EWS is about to leave behind. In short, it gives you just enough functionality to finally start moving off EWS without breaking the workflows that depend on it.
A few things worth understanding upfront:
- REST-based but familiar: It feels like PowerShell but is called over HTTP.
- Everything is POST: Every action, whether it’s viewing or modifying, is done using the HTTP POST method. The request body specifies the cmdlet and its parameters.
- Narrow and intentional scope: This API isn’t trying to be the full Exchange admin surface. It only covers the EWS-driven tasks that didn’t have a modern replacement. Anything outside that, PowerShell still runs the show.
Exchange Online Admin API Capabilities
The Public Preview is live right now (starting November 17, 2025!), and it already packs a punch with six essential endpoints. This API only focuses on a handful of Exchange Online admin tasks. Here are the key areas the Admin API covers right now:
- Organization Configuration: You can query tenant-wide configuration, especially MailTips and similar settings. This is essentially the modern version of GetServiceConfiguration from EWS.
- Accepted Domains: This one lets you list accepted domains and view their key configuration details.
- Mailbox Properties & Delegation: This one is super useful! Because many automations rely on it .You can:
- Read mailbox properties
- View or update Send on Behalf delegates
This replaces the old EWS AddDelegate and RemoveDelegate operations. If you’ve been maintaining any delegation automation through EWS, this is the endpoint for you!
- Mailbox Folder Permissions: Probably one of the most common EWS dependencies. Here you can:
- List folder permissions
- Grant new permissions
- Modify existing permissions
- Remove permissions
It works for Inbox, Calendar, and subfolders — covering the same ground as EWS calls like GetFolder, UpdateFolder, and even some CreateFolder scenarios. If your team manages folder permissions at scale, this endpoint is the direct modern replacement.
- Distribution Group Membership: Retrieve members of regular distribution groups (basically the modern equivalent of ExpandDL).
- Dynamic Distribution Group Membership: Same idea as above, but for dynamic groups. This gives you on-demand access to generated membership lists, which many compliance and reporting workflows still depend on.
The important thing to remember here is that the Admin API isn’t trying to act like a full admin layer. It intentionally covers only the EWS scenarios Microsoft is retiring, nothing more.
If you need advanced mailbox actions, transport rule updates, org-level management, or anything deep in the Exchange engine, PowerShell is still the main tool.
How the Exchange Online Admin API Works
The design is interesting because it blends the familiarity of PowerShell cmdlets with the structure of REST.
- Every request is POST-only. No GET, no PATCH, every operation, even reading data, goes through a POST request.
- You send a JSON payload specifying the cmdlet you want to run.
- You include only the supported parameters, not everything PowerShell has.
- Responses are paged, so large datasets don’t choke your script.
- You can request only the properties you need, reducing payload size.
- Routing uses the X-AnchorMailbox header so your request hits the right backend.
- You authenticate with OAuth and must have the required RBAC role.
If you’ve used Graph API before, this will feel somewhat similar, but with a stronger PowerShell flavor. General Availability isn’t announced yet, and sovereign clouds will take even longer, so you have some time, but not enough to ignore it until 2026.
One thing to note: API responses currently include extra properties during preview. Only the properties listed in the official documentation will remain at GA. So avoid designing anything based on those extra fields.
Admin API vs. Exchange Online PowerShell: When to Use What
This is the part most admins tend to overthink, but the distinction is actually pretty simple. PowerShell is still the complete administrative toolbox for Exchange, which hasn’t changed, and it’s not going anywhere.
- Use the Admin API when you specifically need a REST-first, cmdlet-equivalent surface for the scenarios mentioned above—organization config, group membership, folder permissions, and delegation. Basically, if the task used to rely on EWS and you want to replace that workflow with something modern, secure, and HTTP-based, this API fits perfectly. It’s built for integration into modern, non-PowerShell automation scripts and systems.
- Keep using Exchange Online PowerShell when you need the full breadth of Exchange cmdlets, complex or advanced operations, or if you’re working with existing, proven PowerShell scripts and runbooks.
The Admin API isn’t a competitor; it’s a complementary tool. It ensures that the specific administrative tasks previously tied to EWS have a secure, modern, and high-performance home over HTTP.
If you’ve been delaying your EWS migration because “there’s no replacement yet,” that excuse officially expires now.
This new API finally gives you the missing pieces to modernize your scripts and automations before EWS retires for good in 2026.
