Intune Graph API: Which Calls Are Safe in Production

There is no product called the Intune Graph API. There is Microsoft Graph, and Intune exposes part of itself through it unevenly. Device and app inventory are generally available on the v1.0 endpoint, while scripts, remediations and much of the configuration surface exist only on beta. The obvious approach, picking an endpoint out of the reference and shipping it, fails because Microsoft publishes two different support statements about beta and both are live today. Below is which calls are safe, which are not, and why the 403 you get is usually a renamed permission rather than a bug. It sits inside the wider Intune troubleshooting order, layer by layer.

What the Intune Graph API actually is, and what it is not

It is not a separate API with its own endpoint, its own versioning or its own support contract. It is a set of resources under /deviceManagement inside Microsoft Graph, and the name survives mostly in documentation titles and in blog posts. Treating it as one thing with one support status is the mistake that produces most of the arguments further down this page, because every decision you are about to make is a per resource decision rather than a product level one.

The documentation around it has aged badly, which is worth knowing before you trust a path you found in a search result. Microsoft’s own entry page, Intune devices and apps API overview, still sends readers to an article it calls Use Azure AD to access the Intune API. Azure AD has not been the product name since 2023. The link behind that text moves twice: checked on 21 October 2026, the legacy developer path under mem/intune/developer/intune-graph-apis returns a 301, and the path it names returns a second 301 before landing on the current article, How to Use Microsoft Entra ID to Access Intune APIs in Microsoft Graph. Two redirects from Microsoft’s own index page to the live article is a fair measure of how much attention this corner of the documentation gets, and it is why a good share of the code samples in circulation point at URLs that no longer resolve.

v1.0 or beta: how to tell which one you are on

Check per resource, in the reference, every time. Two examples from the same service show how uneven the split is. List managedDevices is published under v1.0, is available in the global service and in the US Government and 21Vianet clouds, and requires an active Intune licence for the tenant. List deviceManagementScriptAssignments, which is how you read the assignments on a platform script, is published under beta only, and its page tells you to use the version selector to check whether a v1.0 equivalent exists rather than stating that one does.

So the inventory half of Intune is stable and the automation half is not. Anything that changes the estate, platform scripts and remediation scripts in particular, is more likely to sit on beta than the read calls you built your first report with. That is the opposite of the order most teams adopt it in: the proof of concept reads devices from v1.0, succeeds, and creates an expectation of stability that the write half of the work cannot meet.

The quickest way to settle it for a given resource is to ask both endpoints rather than read about it.

1# Ask Graph which endpoint a resource answers on, before committing to it in code.
2# 200 on v1.0 means stable. 404 on v1.0 with 200 on beta means beta only.
3Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$top=1'
4Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts?$top=1'

Write the version into the URL rather than letting a cmdlet or an SDK default decide it. A version that is visible in the diff is a version a reviewer can argue with.

The two support statements that contradict each other

This is the part that decides whether the project is allowed to exist, and it is the reason to read both pages rather than one.

The general Microsoft Graph policy page is unambiguous. On versioning, support, and breaking change policies for Microsoft Graph, Microsoft states: “Use of beta APIs in production applications is not supported.” It goes further: “Expect breaking changes and deprecation of APIs in the beta version from time to time”, and “We make no guarantees that a beta feature will be promoted to the current version.”

The Intune reference pages say something materially different. On List deviceManagementScriptAssignments, and on the Intune beta pages generally, the callout reads: “Microsoft supports Intune /beta APIs, but they are subject to more frequent change. Microsoft recommends using version v1.0 when possible.”

Supported but volatile is not the same claim as not supported. Both sentences were live on 21 October 2026. The narrower, service specific statement is the one that governs Intune resources, which is the ordinary way to read overlapping documentation, but it is published on individual reference pages while the blanket sentence sits on the page that every change board and every security reviewer reads first. That asymmetry is why competent automation work gets refused by people who have done nothing wrong.

If you are the one being refused, the useful move is not to argue about risk appetite. Put the Intune callout in the change record next to the general policy page, name the specific resources you are calling, and let the reviewer decide against the narrower statement that actually applies. If the answer is still no, that is a defensible decision rather than a misreading, and you can plan around it.

The permission model, and why read only still needs an admin

Thirteen application permission scopes cover the service, and they are listed on How to Use Microsoft Entra ID to Access Intune APIs in Microsoft Graph: the Read.All and ReadWrite.All pairs for DeviceManagementApps, DeviceManagementConfiguration, DeviceManagementManagedDevices, DeviceManagementRBAC, DeviceManagementScripts and DeviceManagementServiceConfig, plus DeviceManagementManagedDevices.PrivilegedOperations.All for actions such as wipe and retire.

The sentence on that page that gets missed is this one: “At this time, all Intune permission scopes require administrator access. This means you need corresponding credentials when running apps or scripts that access Intune API resources.” A read only reporting job is still an administrative integration. If the plan was a low privilege service principal that can see device compliance and nothing else, the documentation does not offer you one. The same page states that to manage Intune settings the account needs to be at least an Intune Service administrator.

Graph permissions and Intune RBAC roles and scope tags are also two separate systems. The access article makes no claim that one constrains the other, so do not assume a scope tag on an admin role limits what an application permission can read across the tenant.

The failure modes

A 403 on a call that worked last quarter. The access article records a permission substitution: “As of July 31, 2025, Microsoft Graph replaced use of the DeviceManagementConfiguration.Read.All permission with DeviceManagementScripts.ReadWrite.All for the following API calls”. Read that twice. A Read.All scope was replaced by a ReadWrite.All scope, so an integration that was deliberately read only had to be granted write access in order to keep working. Nothing in your code changed and nothing in your tenant changed. The documented 403 checklist is the right place to start: the application ID in use, whether the credentials support administrative functions, and the scope itself.

A 404 on v1.0 for something you can see in the admin centre. The portal is not restricted to v1.0, so a feature being visible in Intune tells you nothing about which endpoint serves it. Check the reference for that resource instead of assuming parity.

Correct looking data that is quietly incomplete. This is the expensive one, because it never raises an error. A collection GET returns one page and an @odata.nextLink, and code that reads the value array once and stops will under-report the estate for as long as nobody checks a total by hand. The same class of problem exists in the portal: Intune device query has its own result ceiling, and a truncated answer there looks exactly like a complete one too.

Throttling. Graph applies service specific limits and returns a Retry-After header when it rejects a call. I am deliberately not quoting a figure here, because the published Intune limits have changed and the only number worth acting on is the one on the throttling page on the day you read it. Build the retry in before you need it, not after a run has half finished and left the estate in two states.

Schema drift on beta. The same callout that promises support promises more frequent change. A property that is renamed or removed will break a parser that trusted it, and it will do so without the deprecation notice you would get on v1.0, because the beta endpoint does not carry one. If you want to see what a device actually reported rather than what your parser kept, collecting diagnostics from the device is the faster route.

What I would do differently

Keep a list of every beta call the automation makes, in the repository, next to the code. Not for tidiness: so that when a breaking change is announced you can answer the question of what is exposed in minutes rather than by reading everything. This is the single practice that separates an estate which survives a Graph change from one that discovers it in production.

Decide the version per call and write it out in full. Pin it, review it, and treat a move from v1.0 to beta as a change that needs a stated reason, because that is exactly what it is.

Before building paging over managedDevices to get a whole estate view, check whether Intune already publishes what you want as a report export. Reusing a supported export is cheaper than maintaining a collection walk of your own, and it is a question worth asking before the first line is written.

And do not accept a blanket prohibition on beta without showing the reviewer the Intune sentence. The refusal is usually honest and usually based on the wrong page. The Intune Graph API is a reasonable place to automate, provided everyone involved knows which half of it they are standing on.

Last verified: 21 October 2026. Primary sources are linked inline above and were each checked for a live 200 response with no redirect on that date. I have not run this at scale in production; my tenant is a lab with no enrolled devices, so the version split, the two support statements and the permission substitution above are what Microsoft documents today and where I would expect them to bite.