EWS to Microsoft Graph: A Migration Guide for Outlook Add-In Developers

Correction, 3 October 2026: An earlier version of this article said that EWS would stop accepting connections from Outlook add-ins on a single date, 1 October 2026, that it would be blocked for F1 and F3 licence holders from March 2026, and that VSTO add-ins faced an April 2026 migration deadline. None of these is Microsoft’s published position. Microsoft is retiring EWS in Exchange Online in phases: the deprecation began on 1 October 2026, with app allow lists required from 10 October and tenants then switched off individually with seven days’ warning, and EWS is fully and permanently disabled from 1 April 2027. The earlier version also recommended an Outlook REST technique that depends on legacy Exchange tokens Microsoft has turned off, and said the AppID allow list required engagement with Microsoft; it is a setting tenant administrators control. The article has been corrected throughout.

Microsoft is retiring Exchange Web Services (EWS) in Exchange Online in phases. The deprecation began on 1 October 2026, and from 1 April 2027 EWS in Exchange Online will be fully and permanently disabled, with no exceptions. If your Outlook add-in — or the service behind it — relies on EWS for mail retrieval, calendar operations, contact management, or task synchronisation, the migration to Microsoft Graph is not optional. Nor can it necessarily wait until April: once a customer’s tenant has EWS switched off, your EWS calls are blocked there unless an administrator turns EWS back on and allow-lists your app.

This guide is specifically for development teams and IT architects who need to plan and execute the migration from EWS to Microsoft Graph. If you are looking for a guide to building a new Outlook add-in with Microsoft Graph from scratch, we cover that in our article on building an Outlook add-in with Microsoft Graph API.

This article focuses on the distinct engineering challenge of migrating an existing EWS-dependent codebase to Graph equivalents — whether the EWS calls sit in the add-in itself, in the service behind it, or in a VSTO add-in you are replacing at the same time.

The Deprecation Timeline and Key Dates

Understanding the full timeline is essential for migration planning. EWS retirement in Exchange Online is not a single event — Microsoft is disabling it in phases, and on 1 October 2026 the Exchange Team wrote that “the deprecation of EWS in Exchange Online starts today”.

For an add-in vendor, the practical consequence is that EWS can stop working for one customer while it still works for another. A tenant switched to False has EWS blocked for every application. Until 1 April 2027 its administrator can turn EWS back on — by setting EWSEnabled to True with an AppID allow list, or back to Null — but Microsoft notes there will be a service interruption in that case. The seven-day warning is posted to the customer tenant’s Message Center; in our view, you should not count on hearing about it before your users do.

Microsoft had also planned a separate, licence-based restriction: blocking EWS for mailboxes licensed only with Exchange Online Kiosk, F1 or F3, which the service descriptions say do not include EWS access. On 22 September 2026 it cancelled that plan, saying EWS access for those users will be restricted as part of the overall deprecation timeline instead. If your add-in serves frontline workers, there is no earlier date to plan for.

It is also worth clarifying what EWS retirement does and does not affect. It applies to Exchange Online only: Microsoft states that there are no changes to EWS in Exchange Server. If your add-in connects to Exchange Server on-premises, EWS remains available. In hybrid deployments, Microsoft’s guidance is that on-premises mailboxes may continue using EWS while cloud mailboxes must move to Graph, with Autodiscover telling an app where a mailbox lives. However, in our view, planning your add-in architecture around on-premises EWS as a long-term foundation carries obvious risk.

Understanding the Scope of Your EWS Usage

Before planning your migration, map every EWS call in your codebase. EWS usage in Outlook add-ins typically falls into several categories:

Direct EWS calls from add-in code. These are explicit HTTP requests to the Exchange Web Services endpoint, typically using a SOAP envelope. Search your codebase for references to https://outlook.office365.com/EWS/Exchange.asmx or similar EWS endpoint patterns.

EWS via the Managed API. The Exchange Web Services Managed API (Microsoft.Exchange.WebServices) is a .NET wrapper around EWS. Look for it in VSTO add-ins and older web add-in backends.

Server-side EWS calls from add-in backends. Many Outlook add-ins use EWS not in the browser-side Office.js code, but in server-side components that synchronise mailbox data, run background tasks, or process mail server-side. These backend EWS dependencies need migration alongside the client-side code. Where a backend authenticated with an Exchange callback token passed up from the add-in, it has a second problem: Microsoft states that legacy Exchange Online user identity tokens and callback tokens are no longer supported and are turned off across all Microsoft 365 tenants.

EWS through Office.js makeEwsRequestAsync. The Office.js API exposes a makeEwsRequestAsync method that sends an EWS request, proxied through the Office host, to the Exchange server that hosts the user’s mailbox. Microsoft now documents it as a way to use EWS with Exchange on-premises, and its reference entry carries the same notice that legacy Exchange Online tokens are turned off. For mailboxes in Exchange Online, treat every makeEwsRequestAsync call as code to replace with Microsoft Graph.

Creating a complete inventory before estimating migration effort will prevent unpleasant surprises mid-project. Microsoft provides EWS usage reports that show tenant administrators which applications are still calling EWS, and an EWS Analyzer tool to help analyse EWS code.

API Surface Comparison: EWS vs Microsoft Graph

Microsoft describes Microsoft Graph as having reached near-complete feature parity for the vast majority of EWS scenarios, and publishes its own EWS-to-Graph API mappings. It also publishes a roadmap of the remaining gaps — among them in-place archive access, user configuration objects, and availability in sovereign clouds — and advises that if a capability is not on that roadmap, you should not plan on a Graph equivalent arriving before EWS is fully disabled. Check your inventory against that list early. The tables below map the EWS operations that Outlook add-ins most commonly use to their Microsoft Graph equivalents.

Mail Operations

Calendar Operations

Contacts Operations

Tasks Operations

EWS tasks — stored in the Exchange Tasks folder — map to Microsoft Graph’s To Do API; Graph’s older Outlook tasks API is deprecated and no longer returns data. Note that this is a more significant shift than the mail and calendar migrations: To Do organises tasks into task lists and its data model differs from EWS task items, so map fields explicitly rather than assuming a one-to-one equivalence.

Authentication Changes

The authentication architecture change from EWS to Microsoft Graph is one of the most impactful aspects of the migration.

EWS Authentication Methods

EWS integrations behind Outlook add-ins have typically authenticated in one of three ways:

Basic authentication. Username and password sent with each SOAP request. Microsoft has removed Basic authentication for EWS in Exchange Online: it is now disabled in all tenants and can no longer be re-enabled, so an add-in that still relies on it cannot authenticate to EWS in Exchange Online at all.

Exchange callback tokens. The add-in called getCallbackTokenAsync and passed the token to a backend service, which used it to call EWS on the user’s behalf. Microsoft states that legacy Exchange Online user identity tokens and callback tokens are no longer supported and are turned off across all Microsoft 365 tenants (Exchange user identity tokens are still supported on-premises), and recommends MSAL with nested app authentication instead.

Exchange impersonation with service accounts. Server-side EWS applications commonly used a service account with the ApplicationImpersonation RBAC role, allowing the service to make EWS calls on behalf of arbitrary mailboxes. Microsoft has since removed that role from Exchange Online — the deprecation was completed in March 2025 — and pointed EWS applications that need one-to-many mailbox access at app-only OAuth access, scoped with RBAC for Applications, as the alternative to migrating to Graph.

Microsoft Graph OAuth 2.0 via MSAL

Microsoft Graph authentication uses OAuth 2.0 mediated by Microsoft Entra ID (formerly Azure AD). The recommended library is MSAL (Microsoft Authentication Library).

For delegated permission flows — where the add-in acts on behalf of the signed-in user — Microsoft recommends nested app authentication (NAA) for Outlook add-ins. NAA is provided by MSAL.js: you create a nestable public client application, the Office host brokers single sign-on, and the add-in can call Microsoft Graph from the task pane without a middle-tier server. Microsoft’s pattern is to try a silent token request first and fall back to a popup only when interaction is needed:

import {
  createNestablePublicClientApplication,
  InteractionRequiredAuthError
} from '@azure/msal-browser';

const msalInstance = await createNestablePublicClientApplication({
  auth: {
    clientId: 'your-app-client-id',
    authority: 'https://login.microsoftonline.com/common'
  }
});

const tokenRequest = {
  scopes: ['Mail.Read', 'Calendars.ReadWrite', 'Contacts.ReadWrite']
};

let accessToken;
try {
  // Single sign-on through the Office host: no prompt if the user has a session
  accessToken = (await msalInstance.acquireTokenSilent(tokenRequest)).accessToken;
} catch (error) {
  if (!(error instanceof InteractionRequiredAuthError)) throw error;
  // Consent or multi-factor authentication needed: prompt the user
  accessToken = (await msalInstance.acquireTokenPopup(tokenRequest)).accessToken;
}

NAA supports incremental consent, so request only the scopes each operation needs. For Outlook clients on platforms without NAA support, Microsoft positions the older Office single sign-on API (getAccessToken, with the on-behalf-of flow) as a legacy fallback, not a pattern for new code.

For application permission flows — where a server-side component accesses multiple mailboxes without a signed-in user — use the client credentials grant:

import { ConfidentialClientApplication } from '@azure/msal-node';

const cca = new ConfidentialClientApplication({
  auth: {
    clientId: 'your-app-client-id',
    authority: 'https://login.microsoftonline.com/your-tenant-id',
    clientCertificate: {
      thumbprint: 'cert-thumbprint',
      privateKey: fs.readFileSync('./cert.key', 'utf8')
    }
  }
});

const tokenResponse = await cca.acquireTokenByClientCredential({
  scopes: ['https://graph.microsoft.com/.default']
});

Application permissions replace the ApplicationImpersonation pattern from EWS. Instead of a service account with impersonation rights, you register an Entra ID application with the Mail.Read / Mail.ReadWrite (and equivalent) application permissions, which are granted by a tenant administrator. Where impersonation was limited with a management scope, the equivalent control in Exchange Online is RBAC for Applications, which lets administrators restrict an application to a defined set of mailboxes.

The key practical difference: application permissions in Microsoft Graph require admin consent from each tenant that deploys your add-in. This is a change in your onboarding and deployment process, not just your code.

Migration Strategies for Add-Ins Using Both EWS and Office.js

Modern Outlook web add-ins typically use Office.js for item context (accessing the currently-selected email, composing messages in the active compose window) alongside EWS or Microsoft Graph for operations that Office.js does not directly support, such as accessing other mailbox folders, searching the mailbox, or synchronising data.

The migration approach depends on where EWS is being called:

Strategy 1: Replace EWS Calls with Microsoft Graph Calls Directly

For add-ins where EWS calls are made from add-in JavaScript code (including via makeEwsRequestAsync), the migration involves replacing each EWS SOAP operation with the equivalent Microsoft Graph REST call. The Microsoft Graph SDK for JavaScript simplifies this:

import { Client } from '@microsoft/microsoft-graph-client';
import { TokenCredentialAuthenticationProvider } from '@microsoft/microsoft-graph-client/authProviders/azureTokenCredentials';

const authProvider = new TokenCredentialAuthenticationProvider(credential, {
  scopes: ['https://graph.microsoft.com/.default']
});

const graphClient = Client.initWithMiddleware({ authProvider });

// Replace EWS FindItem with Graph messages query
const messages = await graphClient
  .api('/me/messages')
  .filter("isRead eq false")
  .select('id,subject,from,receivedDateTime,bodyPreview')
  .top(25)
  .get();

Strategy 2: Move EWS Logic to a Server-Side Component, Then Migrate

For complex EWS operations, it can be pragmatic to first consolidate all EWS calls into a single server-side service layer, then migrate that layer to Microsoft Graph. This avoids scattering Graph migration work across multiple client-side code paths and makes testing more tractable — you can run EWS and Graph implementations side by side, comparing outputs before switching.

Strategy 3: Combine Office.js Item APIs with Microsoft Graph for the Current Item

Older Outlook add-ins often avoided OAuth altogether by calling the Outlook REST API v2.0 with a callback token from getCallbackTokenAsync({ isRest: true }). That route is closed for Exchange Online: Microsoft has deprecated the Outlook REST v2.0 endpoints and directs new development to Microsoft Graph, and the callback tokens the technique depends on are turned off in all Microsoft 365 tenants.

For operations on the item the user has open, use the Office.js item APIs where they are sufficient — they need no Graph token at all — and call Microsoft Graph with a token from nested app authentication for anything beyond them. Item IDs from Office.js are in EWS format, so convert them with convertToRestId before passing them to Graph:

// Office.js returns an EWS-format item ID; Graph expects the REST format
const itemId = Office.context.mailbox.convertToRestId(
  Office.context.mailbox.item.itemId,
  Office.MailboxEnums.RestVersion.v2_0
);

// accessToken acquired through nested app authentication (see above)
const response = await fetch(
  `https://graph.microsoft.com/v1.0/me/messages/${itemId}?$select=subject,from,receivedDateTime`,
  { headers: { Authorization: `Bearer ${accessToken}` } }
);
const message = await response.json();

convertToRestId is not supported in Outlook on Android and iOS, where itemId is already in REST format.

The Dual Migration Challenge

Some teams are replacing a VSTO or COM Outlook add-in with a web add-in while also removing EWS. The two pieces of work are driven by different things. EWS retirement in Exchange Online has the published, phased timeline above. VSTO and COM add-ins have no equivalent date: Microsoft states that they are not supported in the new Outlook on Windows, and that they are still supported in classic Outlook on Windows. The pressure to replace them comes from the move to new Outlook, not from a retirement deadline. The two migrations still interact in important ways:

A VSTO add-in that calls EWS is caught by EWS retirement too. Not every VSTO add-in uses EWS — many work through the Outlook object model — but some call it directly, often through the EWS Managed API. EWS retirement applies to every application calling EWS in Exchange Online, so a VSTO add-in with an EWS data layer loses that layer when its users’ tenant has EWS switched off, even though the add-in itself still runs in classic Outlook. If your migration path involves rewriting such an add-in as a web add-in, you are not just changing the platform — you are also changing the API layer.

The authentication models differ significantly. A VSTO add-in typically works inside the user’s existing Outlook session, or calls EWS with credentials of its own. Microsoft Graph uses OAuth 2.0 via Entra ID. Migrating both add-in type and API simultaneously means your developers need to understand both the Office.js API surface and the Microsoft Graph API surface, plus MSAL-based token management and nested app authentication — a significant knowledge uplift.

Testing scope doubles. You cannot validate the VSTO-to-web-add-in migration independently of the EWS-to-Graph migration if both are happening in the same codebase. Test plans must cover both dimensions.

Our recommendation for teams doing both: let the EWS timeline set the order, because it is the one with dates attached. Design the web add-in with Microsoft Graph from the outset rather than implementing EWS as a temporary measure in the new web add-in — EWS in Exchange Online is fully disabled from 1 April 2027, so EWS code written into a new add-in now would need replacing within months. If a VSTO add-in has an EWS data layer and its web replacement will not be ready before your customers’ tenants lose EWS, move that data layer to Graph inside the VSTO add-in first. Our article on migrating VSTO and COM add-ins to the Office web add-ins platform covers the platform side of the work.

The EWSAllowedAppIDs Allow List: A Bridge to April 2027, Not a Solution

EWSAllowedAppIDs is a tenant-level AppID allow list that Exchange Online administrators configure themselves, through Exchange Online PowerShell (Set-OrganizationConfig -EwsAllowedAppIDs) or Baseline Security Mode. When EWSEnabled is True, only applications whose App IDs appear on the list can use EWS in that tenant. It is not something you apply to Microsoft for: it is the tenant’s own control.

What it does during the retirement window:

• From 10 October 2026, in the worldwide cloud, it is required: a tenant with EWSEnabled = True and no allow list has all EWS blocked.
• Shortly before switching a tenant from Null to False, Microsoft populates the list from that tenant’s previous 60 days of EWS usage. Microsoft is clear that the administrator owns making sure the list is correct.
• Changes to the list take up to 24 hours to take effect; changes to EWSEnabled typically take under an hour, but can take up to four.
• It stops mattering on 1 April 2027, when EWS is fully disabled and administrators lose the ability to control EWSEnabled. Microsoft has said there will be no exceptions past April 2027.

For an add-in vendor, our practical advice:

• Publish the application (client) ID your EWS code authenticates as, so your customers’ administrators can add it to their allow lists while you finish migrating.
• Treat allow-listing as your customers’ decision, not yours. Some may prefer to block EWS entirely rather than keep a third-party application on the list.
• Plan to have no EWS dependency left in Exchange Online before 1 April 2027 — and earlier for any customer whose tenant is switched off and who chooses not to turn EWS back on.

Do not use the allow list as an excuse to defer migration planning. It buys time only until 1 April 2027, and only in tenants whose administrators choose to use it.

Testing Your Microsoft Graph Migration

Validating that the migrated Microsoft Graph implementation is behaviourally equivalent to the EWS implementation requires a structured approach:

Functional Equivalence Testing

For each migrated operation, create tests that verify the Microsoft Graph response contains the expected data fields. Be aware that field names differ between EWS and Graph: for example, EWS DateTimeSent becomes sentDateTime in Graph, and EWS DateTimeReceived becomes receivedDateTime. Item IDs differ too — if your backend stores EWS item IDs, convert them with Graph’s translateExchangeIds, the equivalent of EWS ConvertId.

Pagination Handling

EWS uses FindItem with IndexedPageItemView for pagination. Microsoft Graph uses OData $top and $skip parameters, or nextLink cursors for server-side pagination. Migrated code must handle Graph’s pagination model, which differs from EWS’s offset-based approach.

// Graph pagination using nextLink
async function getAllMessages(graphClient) {
  const messages = [];
  let response = await graphClient
    .api('/me/messages')
    .top(100)
    .get();

  messages.push(...response.value);

  while (response['@odata.nextLink']) {
    response = await graphClient
      .api(response['@odata.nextLink'])
      .get();
    messages.push(...response.value);
  }

  return messages;
}

Permissions Validation

Test your add-in with users who have different permission levels and licence types. Pay particular attention to:

• Users in national clouds, such as Microsoft Cloud for US Government or Microsoft 365 operated by 21Vianet, where app registration, token and Graph endpoints differ from the global service — and where Microsoft’s parity-gap roadmap still lists sovereign cloud availability of the Exchange APIs needed for EWS migration.
• Shared mailboxes, which require specific Graph permission configurations.

Change Notification Testing

If your add-in uses EWS streaming or push notifications to detect new mail or calendar changes, the migration to Microsoft Graph change notifications (webhooks) requires specific testing. Graph change notifications are delivered via HTTPS POST to a webhook endpoint (or through Azure Event Hubs or Azure Event Grid), and your add-in’s notification processing infrastructure will need to be rebuilt to receive and validate these messages. Subscriptions expire and must be renewed, and subscriptions to Outlook messages, events and contacts support lifecycle notifications that warn you when a subscription has been removed or notifications may have been missed — test your recovery path, not just the happy path. If you used EWS pull notifications, Microsoft maps those to delta queries rather than subscriptions.

Performance Benchmarking

EWS SOAP requests and Microsoft Graph REST calls have different performance characteristics. If your add-in performs bulk operations — retrieving large numbers of messages, processing calendar ranges — benchmark the Graph implementation under production-representative load before go-live. When Graph throttles a client it returns HTTP 429 with a Retry-After header, so make sure your code honours it under load.

Registering Your Application in Microsoft Entra ID

Before your add-in can make Microsoft Graph calls, you must register it in Microsoft Entra ID. The app registration is foundational to the migration:

1. In the Azure portal, navigate to Microsoft Entra ID > App registrations > New registration.
2. Provide a name and set the supported account types (single tenant, multitenant, or personal accounts as appropriate for your add-in audience).
3. Configure the redirect URI. For nested app authentication, add a single-page application redirect of the form brk-multihub://your-add-in-domain — the origin only, with no path.
4. Under API permissions, add the Microsoft Graph permissions required for your operations. Use delegated permissions for user-context operations and application permissions for service-to-service access.
5. For application permissions, submit an admin consent request — or, during development, use the “Grant admin consent” button in the portal if you have the appropriate Entra ID role.
6. Generate a client secret (for development) or configure certificate credentials (for production).

Document the required permissions clearly. When your add-in is deployed to a new tenant, an administrator must consent to those permissions. Unexpected permission scopes discovered during deployment will stall your rollout.

Get Expert Help with Your EWS Migration

EWS retirement in Exchange Online is under way, and 1 April 2027 is the date after which no tenant can keep EWS running. The technical scope of an EWS-to-Graph migration is easy to underestimate: the API surface change, the authentication architecture change, the pagination model change, and the shift in how permissions are granted all require careful design and thorough testing.

For organisations also replacing VSTO or COM add-ins, the sequencing matters. In our view, the costly mistakes are building EWS into a new web add-in, or leaving an EWS data layer in a VSTO add-in on the assumption that classic Outlook will protect it until the web replacement is ready — it will not, because EWS retirement does not depend on which Outlook client the user runs.

McKenna Consultants is a UK-based Office add-in development consultancy with deep expertise in both Office.js web add-in development and Microsoft Graph API integration. For Workiro, we built a Microsoft Outlook add-in alongside a Microsoft Graph server-side integration that lets users tag, import and sync email conversations into the Workiro platform.

If you are planning your EWS-to-Microsoft-Graph migration and need architectural guidance, implementation support, or an independent review of your migration plan, contact McKenna Consultants to discuss your requirements. We can help you move to a fully migrated, Graph-native add-in before EWS is switched off in your customers’ tenants — without disrupting users in the process.

Sources

• Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online: the 2018 and 2023 announcements, EWS starting to be disabled in October 2026 and fully disabled in April 2027, Microsoft’s parity-gap roadmap and its advice on capabilities not listed, EWS usage reports and the EWS Analyzer.
• Exchange Team Blog — Exchange Online EWS, Your Time is Almost Up: the phased, admin-controllable disablement announced in February 2026, the EWSEnabled values, re-enabling EWS before final deprecation and the resulting service interruption, full and permanent disablement from 1 April 2027 with no exceptions, no change to EWS in Exchange Server, hybrid guidance, and Microsoft’s description of Graph parity.
• Exchange Team Blog — EWS deprecation is here – what this means to you: the deprecation starting on 1 October 2026, the allow list requirement from 10 October in the worldwide cloud, the second phase with a seven-day Message Center warning, allow lists populated from 60 days of usage, and how long setting changes take.
• Exchange Team Blog — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement: what the AppID allow list is, how it interacts with EWSEnabled, how administrators set it, and the administrator’s ownership of its contents.
• Exchange Team Blog — Update to EWS Access for Kiosk / Frontline Worker Licensed Users: the licence-based restriction for Kiosk, F1 and F3 users, and its cancellation on 22 September 2026.
• Microsoft Learn — Authentication options in Outlook add-ins: legacy Exchange Online identity and callback tokens turned off across all Microsoft 365 tenants, MSAL and nested app authentication recommended, and the legacy on-behalf-of single sign-on pattern.
• Microsoft Learn — Enable single sign-on in an Office add-in with nested app authentication: the brk-multihub redirect URI, createNestablePublicClientApplication, incremental consent, and the silent-then-popup token pattern.
• Microsoft Learn — Use Exchange Web Services (EWS) from an Outlook add-in in Exchange on-premises: makeEwsRequestAsync documented for Exchange on-premises.
• Microsoft Learn — Office.Mailbox interface: makeEwsRequestAsync and its legacy token notice, and convertToRestId converting EWS-format IDs for REST APIs such as Microsoft Graph.
• Microsoft Learn — Use the Outlook REST APIs from an Outlook add-in: deprecation of the Outlook REST v2.0 endpoints, Microsoft Graph for new development, and REST-format item IDs on mobile.
• Microsoft Learn — Exchange Web Services (EWS) to Microsoft Graph API mappings: Graph equivalents of EWS operations, including SyncFolderItems to message delta, pull notifications to delta, and ConvertId to translateExchangeIds.
• Microsoft Learn — message: delta: the folder-level message delta endpoint.
• Microsoft Learn — Use $search Query Parameter in Microsoft Graph APIs: searching messages with $search.
• Microsoft Learn — Get user photos by using EWS in Exchange: contact photos retrieved in EWS with GetItem followed by GetAttachment.
• Microsoft Learn — To Do API overview: To Do task lists and the deprecated Outlook tasks API.
• Microsoft Learn — Deprecation of Basic authentication in Exchange Online: Basic authentication disabled in all tenants, including for EWS, and no longer re-enableable.
• Exchange Team Blog — Critical Update: ApplicationImpersonation RBAC Role Deprecation in Exchange Online: removal of the ApplicationImpersonation role, completed in March 2025, and the recommended alternatives.
• Microsoft Learn — Role Based Access Control for Applications in Exchange Online: restricting an application’s access to specific mailboxes.
• Microsoft Learn — Overview of Microsoft Graph permissions: administrator consent for application permissions.
• Microsoft Learn — Microsoft Graph national cloud deployments: the national clouds and their separate registration, token and Graph endpoints.
• Microsoft Learn — Set up notifications for changes in resource data and Change notifications for Outlook resources in Microsoft Graph: webhook, Event Hubs and Event Grid delivery, subscription renewal, and lifecycle notifications.
• Microsoft Learn — Microsoft Graph throttling guidance: HTTP 429 responses and the Retry-After header.
• Microsoft Learn — Develop Outlook add-ins for the new Outlook on Windows: VSTO and COM add-ins not supported in the new Outlook on Windows, and still supported in classic Outlook on Windows.