Microsoft froze Exchange Web Services feature development in July 2018, yet plenty of mailboxes still answer only over EWS. The reason is deployment: an Exchange mailbox lives either on a server the customer runs themselves or in Microsoft’s cloud, and those two worlds speak different protocols. EWS is the SOAP API for on-premises Exchange Server. Microsoft Graph is the REST API for Exchange Online and Microsoft 365.
This page compares the two for email integration, explains which one a given mailbox forces on you, and shows how to connect both through one schema. For the EWS connect flow itself, see connect Exchange (EWS) accounts. For a deeper Graph comparison against the unified API, see the Microsoft Graph alternative.
EWS vs Microsoft Graph: Which one applies?
Section titled “EWS vs Microsoft Graph: Which one applies?”The mailbox decides, not your preference. If the organization runs Exchange Server in its own data center, you reach it over EWS, a SOAP protocol shipped with Exchange 2007 and later. If Microsoft hosts the mailbox in Exchange Online, Microsoft 365, or Outlook.com, you reach it over Microsoft Graph, the REST API behind OAuth. No mailbox uses both.
This is the single biggest source of confusion when teams plan an Exchange integration. “Exchange” names two unrelated systems that share a brand. On-premises Exchange predates cloud OAuth and requires direct network calls to a specific server address and port. Exchange Online sits behind Microsoft’s managed Graph endpoint at graph.microsoft.com. The table below maps the practical differences across the 6 dimensions that drive integration work.
| Dimension | EWS (on-prem Exchange) | Microsoft Graph (Exchange Online) |
|---|---|---|
| Deployment | Self-hosted Exchange Server 2007+ | Exchange Online, Microsoft 365, Outlook.com |
| Protocol | SOAP / XML over HTTPS | REST / JSON over HTTPS |
| Auth | Basic or NTLM (server-configured) | OAuth 2.0 only, since Oct 1, 2022 |
| Read mail | FindItem then GetItem SOAP calls | GET /me/messages with Mail.Read |
| Sync | SyncFolderItems SOAP operation | Delta query on /me/messages/delta |
| Future | Retires in Exchange Online; lives on-prem | Microsoft’s recommended, actively-developed API |
| Through Nylas | ews connector, one unified schema | microsoft connector, one unified schema |
When should you use EWS instead of Microsoft Graph?
Section titled “When should you use EWS instead of Microsoft Graph?”Use EWS when the mailbox runs on a self-hosted Exchange server your customer controls, because Graph can’t reach a server that isn’t in Microsoft’s cloud. Exchange Server 2007 and later expose EWS; Exchange 2010 adds starred-message support. If the mailbox is in Exchange Online or Microsoft 365, Graph is the correct and future-proof choice.
The split is binary, but the gray area is enterprises mid-migration. A single tenant can have some mailboxes already moved to Exchange Online and others still on an on-prem server during a hybrid migration. In that case you need both paths at once. Don’t try to force one protocol across the estate. EWS speaks SOAP and authenticates with the credentials the server accepts, commonly Basic or NTLM over TLS. Graph speaks REST and requires an OAuth token from Microsoft Entra. Treat them as two integrations that happen to share a vendor, and you’ll avoid the trap of assuming a Graph token works against an on-prem box.
Does the Basic Auth deprecation affect EWS?
Section titled “Does the Basic Auth deprecation affect EWS?”It depends on where the mailbox lives. Microsoft disabled Basic authentication for Exchange Online, including EWS, POP, IMAP, and ActiveSync, on October 1, 2022, so Graph and OAuth are the only options in the cloud. On-premises Exchange Server isn’t affected: those servers still accept Basic and NTLM authentication for EWS.
This distinction trips up teams who read the 2022 headlines and assume EWS is dead everywhere. It isn’t. The deprecation, documented in Microsoft’s Basic authentication deprecation guide, targets Exchange Online only. According to that guide, “Basic authentication is now disabled in all tenants” for the cloud service. An on-prem server administered by your customer keeps whatever auth the admin configures. So an EWS integration against on-prem mail using a username and password still works today, while the same Basic-auth approach against an Exchange Online mailbox stopped working in 2022. When Nylas connects an on-prem account, the user signs in with their Exchange username, formatted as [email protected] or DOMAIN\username.
When does EWS stop working?
Section titled “When does EWS stop working?”EWS retires on different timelines depending on deployment. For Exchange Online, Microsoft announced retirement in 2022 and begins phased disablement on October 1, 2026, with permanent shutdown on April 1, 2027. On-premises Exchange Server has no announced EWS retirement date, so EWS remains the supported path for self-hosted mailboxes.
Microsoft stopped shipping EWS feature updates in July 2018 and points cloud developers to Graph, which it says has reached near-complete feature parity for most EWS scenarios. Two milestones matter before the October 2026 cliff for Exchange Online: in mid-2026, Microsoft begins blocking EWS for users on Kiosk and Frontline licenses, and by the end of August 2026 admins must allow-list apps and set EWSEnabled=True to keep EWS running past the deadline. Microsoft’s EWS retirement announcement covers the phased plan. None of this touches on-prem Exchange, where EWS is still the only API many servers expose. That asymmetry is exactly why an integration that supports both deployments outlives the cloud retirement.
How does Nylas connect both EWS and Graph?
Section titled “How does Nylas connect both EWS and Graph?”Nylas fronts both protocols with one schema, so you read mail through GET /v3/grants/{grant_id}/messages whether the grant points at an on-prem EWS server or an Exchange Online mailbox on Graph. You pick the protocol once, at connector creation, by setting provider to ews or microsoft. After that, every email, calendar, and contact call uses the same grant ID and the same response shape.
The two connectors map cleanly to the two deployments. The ews connector handles self-hosted Exchange and takes scopes like ews.messages, ews.calendars, and ews.contacts; create one per data type. The microsoft connector handles Exchange Online over Graph and uses OAuth scopes such as Mail.Read. The request below reads mail from a connected account and returns up to 50 messages per page, identical whether the underlying provider is EWS or Graph. Swap the grant ID and the call stays the same. Replace the bearer token with your API key before running it.
curl --request GET \ --url "https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages?limit=50" \ --header "Authorization: Bearer <NYLAS_API_KEY>"from nylas import Client
nylas = Client(api_key="<NYLAS_API_KEY>")
messages = nylas.messages.list( "<NYLAS_GRANT_ID>", query_params={"limit": 50},)
for message in messages.data: print(message.subject, message.from_)Because the schema is shared, supporting a hybrid tenant means connecting some mailboxes through the ews connector and others through microsoft, then writing one parser for both. The same grant model also reaches Google, Yahoo, iCloud, and IMAP, so adding another provider later costs no new code path.
What’s next
Section titled “What’s next”- Connect Exchange (EWS) accounts for the full EWS connector and grant flow
- Microsoft Graph alternative to compare Graph against the unified API for Exchange Online
- Authenticating Exchange on-premises accounts for server setup, minimum versions, and autodiscovery
- List Microsoft email messages for the unified read call on Exchange Online accounts