Today, we are announcing the Public Preview of the Exchange Online Admin API – a REST based, cmdlet style administrative surface specifically designed to help organizations migrate away from EWS for ...
Published Nov 17, 2025
Version 1.0
Blog Post
Cool! But some initial questions:
- Why isn't this behind Microsoft Graph? Is Graph no longer the goal for M365 API unification?
- Why would we use POST to GET object properties?
VivekMicrosoft
Hi Mike, the Exchange Online Admin API is REST-based, though not fully REST-ful, as its primary goal is to provide a fast and dependable replacement for key EWS Exchange scenarios and close any parity gaps ahead of the October 2026 deprecation timeline. To deliver this functionality quickly and without compromising coverage, the service currently wraps a subset of Exchange cmdlets as REST endpoints. Since the API endpoints are not truly RESTful, all requests use POST method, including those that retrieve data, and the API is not exposed through Microsoft Graph.
Regarding requirements for Graph or fully REST-ful endpoints for Exchange admin scenarios, we are actively gathering customer input. Recently a blog post was published for collecting the customer feedback that includes a feedback form where you can share your requirements, scenarios, and expectations for REST or Graph-based admin capabilities. The link to the blog post is as follows: Give us feedback on Exchange Online Cmdlet changes and Rest API availability for Admin Scenarios | Microsoft Community Hub. If you haven’t already, please do share your feedback through the forms in the blogpost.
I suppose because it isn't a clean REST API that fits in the more clean Graph approach. If you look at the bodies send via POST you see that you have to send the Cmdlet Name and parameters just like you could have done using the cmdlet in Powershell. So we can assume that they simply execute those Powershell cmdlets server side. Easy cheap shot to get something working without the burden of a clean new API design fitting into Graph. This API feels more like an abomination to me. Or phrased differently to replace an API with a different one and then feeling the need to create a third API to fill parts of the most abysmal holes it leaves open does not feel right.
I have the same question (#1).
