Microsoft Graph API + Microsoft Graph PowerShell Enterprise Guide (2026)

Microsoft Graph API is the unified REST API surface for Microsoft 365, Entra ID, Defender, Purview, Copilot, Teams, SharePoint, OneDrive, and the broader Microsoft Cloud — every endpoint lives under graph.microsoft.com. The Microsoft Graph PowerShell SDK is an auto-generated PowerShell module that wraps the REST API in cmdlets — Get-MgUser, New-MgGroup, Update-MgApplication, and so on. The SDK is the modern replacement for the deprecated AzureAD, MSOnline, and AzureADPreview PowerShell modules — every script touching Entra or Microsoft 365 in 2026 should be on the Graph SDK, not the legacy modules. The two share the same permission model, the same authentication patterns, the same throttling behavior, and the same Beta versus v1.0 endpoint distinction — the SDK is a transport convenience, the API is the underlying contract. Pick the API for application code, pick the SDK for administrative scripting and PowerShell-based automation.

Delegated permissions run as a signed-in user — the access token Graph receives carries the user identity, and Graph enforces both the application permission grant and the user-level permission together. The user can only see what they have access to plus what the app is allowed to ask for. Application permissions (also called app-only or daemon permissions) run as the application itself — there is no signed-in user, the access token carries only the application identity, and Graph enforces only the application permission grant scoped tenant-wide. Application permissions are required for background automation, scheduled jobs, and any scenario where no user is interactively present. Delegated permissions are required for any user-facing application where retrieval should honor the user identity (Copilot grounding, user-driven mail or calendar access, user-scoped Search). The most common architectural mistake is using application permissions where delegated permissions belong — bypassing the user identity and breaking sensitivity-label enforcement.

Any application permission and any delegated permission marked as admin-consent-required must be granted by a tenant administrator before any user (or the application itself) can exercise the permission. The flow has two paths. The admin consent endpoint — https://login.microsoftonline.com/{tenant}/adminconsent — lets a tenant administrator pre-grant consent for the entire tenant in one step, after which any user in the tenant can authenticate against the app without an individual consent prompt. The runtime consent flow — the first time a user (or application) signs in, the consent screen surfaces requested permissions and either the user grants (if user consent is allowed for that permission scope) or the request is blocked pending admin consent. Enterprise practice is to pre-grant admin consent at deployment time and disable user consent for all but the lowest-risk permission scopes — every modern Entra tenant should have admin consent workflow enabled with a request approval queue in the Entra admin center.

Microsoft Graph throttles per resource, per tenant, and per application identity, with limits varying by endpoint family (Outlook mail, SharePoint, Teams, Entra each have their own published limits). The correct strategy combines four patterns. First — batching via /$batch lets up to twenty individual requests pack into a single HTTP call, reducing throttling pressure dramatically for any chatty workload. Second — exponential backoff with jitter on HTTP 429 responses honors the Retry-After header rather than using a fixed retry interval. Third — change notifications and delta query replace polling — push-based eventing is fundamentally cheaper than poll-based retrieval and avoids the throttling pressure polling creates at scale. Fourth — separate application identities per workload partition throttling pressure across multiple service principals rather than concentrating on one. Any production Graph integration above a few thousand users should layer all four patterns from Day 1, not retrofit them after throttling becomes the operational problem.

It depends on the specific endpoint. Microsoft Graph publishes two API versions — v1.0 and Beta. v1.0 endpoints carry an SLA and a deprecation policy that gives twenty-four months notice on breaking changes. Beta endpoints carry no SLA and can change without notice. The official Microsoft position is that Beta is for evaluation only and production code should target v1.0. The practical enterprise reality is that some Beta endpoints have been stable for years (parts of the security and compliance Graph were Beta-only for an extended period) and have effectively become production-grade in customer use even before formal v1.0 promotion. The decision framework EPC Group applies — only use Beta when v1.0 cannot deliver the capability, document the dependency in the deployment record, monitor Microsoft Graph changelog for the endpoint, and architect a fallback to v1.0 or to the underlying admin center as soon as the v1.0 endpoint ships. Never use Beta for any audit, compliance, or regulatory data path — those must run on the SLA-backed v1.0 surface.

The enterprise pattern for any Azure-hosted automation calling Microsoft Graph is system-assigned managed identity. Enable the managed identity on the Function App, App Service, Container App, Logic App, or Virtual Machine. Grant the managed identity the required Graph application permissions through the Entra admin center or PowerShell (New-MgServicePrincipalAppRoleAssignment). At runtime, the Azure SDK or DefaultAzureCredential acquires a token from the managed identity endpoint, the token carries the managed identity service principal as the authenticated identity, and Graph honors the granted application permissions. The pattern eliminates secret rotation entirely — there is no client secret or certificate to manage, no Key Vault dependency, no shared credential. Federated credentials extend the same pattern to non-Azure execution contexts — GitHub Actions, Kubernetes service accounts, and external CI/CD pipelines can authenticate to Entra without stored secrets through federated credential trust. Managed identity plus federated credential is the modern enterprise answer to the secret-rotation problem that historically dominated Graph automation operational toil.

Microsoft Graph change notifications are HTTPS webhooks the customer registers via POST /subscriptions, with a clientState shared secret, a notificationUrl pointing to a customer-owned endpoint, and a lifetime measured in days (three days for most resources, less for some). When subscribed resources change, Graph sends a POST to the notificationUrl with the affected resource path. At scale three things fail first — first, the renewal cadence (most subscriptions need refresh every three days and a missed renewal means missed events permanently, so renewal automation is non-negotiable); second, the notification endpoint throughput (Graph batches notifications but at peak a real tenant can push thousands per second so the endpoint must scale horizontally with idempotent processing); third, the validation handshake on subscription creation (Graph posts a validation token the endpoint must echo within ten seconds — slow cold starts on Azure Functions can fail validation). For high-volume scenarios above a few thousand notifications per second, Event Hub destination replaces direct webhook — Graph writes notifications into an Event Hub for the downstream system to consume with native back-pressure handling.

Microsoft 365 Copilot and any Copilot Studio agent grounding on Microsoft 365 content call Microsoft Graph as the retrieval transport. The Microsoft Search endpoint (/search/query) unifies retrieval across Outlook mail, calendar, OneDrive files, SharePoint sites, and Teams chat. Critically — Graph honors the user identity in delegated permission tokens, so retrieval scopes to what the user can already see, and Purview sensitivity labels propagate through Graph into the retrieval result. This is how Copilot enforces label-aware grounding without any custom code — the Entra identity carries through, the Purview label carries through, and content the user cannot see is automatically excluded. The architectural implication for custom agents is significant — calling Graph with delegated permissions on the user identity gives label-aware retrieval for free, while calling Graph with application permissions (app-only) bypasses both user identity and label enforcement. Cross-link to the Copilot Studio agents enterprise guide for the full integration patterns.