Announcing General Availability for Azure Resource Graph (ARG) GET/LIST API

JaspreetKaur

Microsoft

Dec 03, 2025

We’re excited to announce the General Availability of the Azure Resource Graph (ARG) GET/LIST API

ARG GET/LIST API delivers 10X higher throttling quotas to callers compared to ARG query unlocking a more scalable, resilient way to perform resource lookups in Azure. ARG GET/LIST API is a new platform capability within Azure Resource Graph that provides a high-performance experience for both Point GET and collection GET requests. A key advantage of this capability is its ability to significantly reduce READ throttling for high volume calls efficiently. This is made possible through intelligent control plane routing based on a query parameter controlled by the caller. When a specific query parameter is included, requests are automatically directed to this optimized ARG GET/LIST backend. When the parameter is omitted, requests flow to the Resource provider —ensuring flexibility and backward compatibility.

What Challenge Are We Addressing?

Azure Read Throttling is a significant challenge for many customers. When services hit throttling limits, applications may experience performance degradation, elevated latency, or even failed requests—issues that can disrupt critical workloads and customer operations.

The ARG GET/LIST API is designed to directly address this problem. By routing GET and LIST calls through Azure Resource Graph’s scalable indexing infrastructure and intelligent control-plane routing, it dramatically reduces the likelihood of read throttling. Best of all, it follows the ARM control plane GET APIs request response contract, allowing you to benefit from improved performance and reliability with minimal effort, appending the flag “useResourceGraph=true”.

When to use Azure Resource Graph (ARG) GET/LIST API

The ARG GET/LIST API is designed for scenarios where you need to retrieve a single resource by its ID or list resources of the same type within a defined scope—whether that's a subscription, resource group, or parent resource.

You should consider using the ARG GET/LIST API if your service fits into one or more of the following categories:

High Volume of GET Calls Within a Single Scope:
Your service issues a large number of GET requests targeting resources within a single subscription or resource group, without the need for cross-subscription queries, complex filters, or joins.
Risk of Throttling or Quota Competition:
Your service produces a high volume of requests and may encounter issues such as::
- Experience throttling during sudden traffic spikes.
- Quota competition, where other workloads in the same subscription consume shared quota limits, causing your service to be throttled.
- Bursty traffic patterns, where large volume of GET requests are issued within a short time window, increasing the chance of throttling.
Need for High Availability and Faster Performance:
Your service depends on consistent; low-latency GET operations for either single-resource lookups or listing resources within a specific scope

Note: The ARG GET/LIST API is currently supported only for resources in the resources and computeresources tables.

Using the ARG GET/LIST API

To get started with the ARG GET/LIST API, begin by assessing whether your scenario aligns with the recommended calling patterns and throttling considerations described earlier. Once confirmed, simply append the parameter &useResourceGraph=true to your eligible GET/LIST API calls. This flag routes your request through the Azure Resource Graph GET/LIST API backend, allowing you to take advantage of its optimized performance and query efficiency. No calls will route to ARG GET/LIST backend automatically. The switch is entirely in the user’s control—the call will route to ARG GET/LIST API only when you explicitly include the useResourceGraph=true parameter in your request.

Follow the ARG GET/LIST API contract here - Azure Resource Graph GET/LIST API Guidance - Azure Resource Graph | Microsoft Learn

Let’s walk through a simple example of retrieving a Virtual Machine (VM) along with its InstanceView through ARG Query vs. ARM API vs. ARG GET/LIST API to show the difference in the calling experience.

Using an ARG Query (via ARG Explorer)

In ARG Explorer, you can use Kusto Query Language (KQL) to query resources.
A sample query to retrieve a specific VM looks like this:

Resources
| where type =~ 'microsoft.compute/virtualmachines'
| where id =~ '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}'

This query filters the Resource Graph index to return the VM resource.

Using the ARM (Compute RP) API

The equivalent ARM API call to retrieve the VM with InstanceView is:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView

This hits the Compute Resource Provider, pulls the VM state, and expands the instanceView section.

Using the ARG GET/LIST API

ARG GET/LIST APIs that follow the same request structure as ARM—but with an additional flag that routes the call through ARG:

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.compute/virtualmachines/{vm}?api-version=2024-07-01&$expand=instanceView&useResourceGraph=true

The important distinction here is the useResourceGraph=true parameter, which routes the call through ARM to serve the response through ARG’s GET/LIST backend.

Sample Response -