What is Microsoft Graph?

What is Microsoft Graph?

Microsoft Graph is the unified REST API for Microsoft's cloud. One base URL - https://graph.microsoft.com - covers the data and policies that sit behind Microsoft 365, Entra (formerly Azure AD), Windows, and Intune. Users, mailboxes, calendars, OneDrive files, SharePoint sites, Teams chats, groups, devices, sign-in logs, app registrations - all of it lives behind the same endpoint, with the same auth contract.

The name is the metaphor. The directory plus everything attached to it - the people, the things they own, the things they belong to, the things they touch - forms a graph of related resources. Graph the API is how you walk that graph from code.

Microsoft Graph is the gateway to data and intelligence in Microsoft 365. It provides a unified programmability model that you can use to access the tremendous amount of data in Microsoft 365, Windows, and Enterprise Mobility + Security.- Microsoft Learn

The practical version: if you have ever wanted to list a user's mailbox folders, post a message to a Teams channel, read someone's calendar, upload a file to OneDrive, or pull the members of an Entra group from a script - Graph is the API you call.

One door for the Microsoft cloud

Before Graph, each Microsoft service had its own API: a Mail API for Exchange, a separate one for OneDrive, another for SharePoint, another for Entra. Different endpoints, different auth flows, different SDKs, different versioning. Graph collapses them into one surface.

That consolidation is the point. One token works across services. One pagination model, one query syntax, one error format, one SDK per language. If you already know how to list users, you already know roughly how to list groups, files, or events - only the path changes.

Two related surfaces are worth naming so they don't get confused with Graph itself. The Microsoft identity platform is the OAuth 2.0 / OpenID Connect endpoint your app calls to get a token; Graph is what you call with that token. And the older, service-specific APIs (Outlook REST, Azure AD Graph) still exist in old code and old docs - but new work goes through Microsoft Graph.

The shape of a Graph call

Every Graph call is plain HTTPS - a verb, a path, a bearer token, and optional query parameters. The path always starts with a version segment (v1.0 for stable, beta for preview) followed by a resource.

The same handful of resources covers most of what people reach for Graph to do:

The query layer is OData. The $select, $filter, $top, $expand, $orderby, and $search parameters work consistently across resources - so a filter you learn for users transfers to messages, files, or events. Responses are JSON; collections paginate with an @odata.nextLink URL you follow until it is missing.

Auth and permissions

Every Graph call needs a bearer token from the Microsoft identity platform. You get one by registering an application in Entra ID, declaring which Graph permissions it needs, and going through an OAuth 2.0 flow. Tokens are scoped: a token with Mail.Read can read mail and nothing else.

The first fork to understand is who the token represents. Graph has two permission types, and a real app usually picks one per scenario.

Two rules carry most of the consequences. Pick the smallest permission that works - User.Read reads the signed-in user's profile and stops there; User.Read.All reads every user in the tenant. The high-privilege variants need explicit admin consent, and Conditional Access policies will reach in and inspect them.

And respect throttling. Graph enforces per-tenant and per-app rate limits, returning 429 Too Many Requests with a Retry-After header when you cross one. Production code reads that header and waits.

SDKs and Graph Explorer

You can call Graph with anything that speaks HTTPS - curl, fetch, an HTTP library in your language of choice. For real apps, Microsoft ships official SDKs that handle token acquisition, retries, pagination, and request-building so you do not write that plumbing yourself.

The official SDKs cover JavaScript / TypeScript, .NET, Java, Python, Go, PHP, and PowerShell (the Microsoft.Graph module). The shape is similar across them: a client, a fluent api(path) builder, typed responses where the language supports it.

Before you write any SDK code, spend ten minutes in Graph Explorer. It is a browser tool that lets you sign in to a tenant - your own or Microsoft's sample tenant - pick any endpoint, run the request, and see the JSON. It is the fastest way to learn the shape of a resource, find the permission a call needs, and copy a working snippet into your codebase.

What you build with it

Most uses of Graph cluster into a few shapes. You will recognize them once you start looking.

• Automation across the tenant. Onboarding and offboarding scripts: create users, add them to groups, license them, provision a OneDrive, schedule a welcome email - all from one script with one token.
• Reporting and audit. Pull sign-in logs, license usage, group membership, mailbox sizes, or Teams activity into a warehouse. The data lives in Graph; getting it out is a paginated GET.
• App integrations. A third-party app that wants to read a user's calendar to suggest meeting times, attach a file from OneDrive, or post a status to a Teams channel goes through Graph with delegated permissions.
• AI agents and copilots. Tools and agents that act inside Microsoft 365 - read context from mail and files, take actions on the user's behalf - call Graph for both. Microsoft 365 Copilot is itself built on top of it.

The through-line: when the data you need lives somewhere inside Microsoft 365, Entra, or Windows, and you want to read or change it from code, Graph is almost always the answer. The few exceptions are Azure resource management (that is the Azure Resource Manager API) and some specialized security and compliance surfaces - but for the everyday "user, file, message, group, device" shaped problems, it is one endpoint.