Request_UnsupportedQuery: Microsoft Graph rejected your query parameters

What does Request_UnsupportedQuery mean?

Graph parsed your request, recognised the resource, and then refused to run the query you attached to it. HTTP 400.

The code itself is generic and covers several unrelated mistakes, and the quality of the message varies. Most of the ones measured below name the property, the operator or the value at fault, and two name the header you need to add — but one, Sorting not supported for current query., names nothing useful at all.

Microsoft’s current Graph error reference contains no table of named error codes at all — only HTTP status codes — so there is no current Microsoft page that defines this string. The only Microsoft page that does define it is the retired Azure AD Graph catalogue, last updated in 2016 and carrying a retirement caution, where the description reads “The GET request is unsupported. Fix the request parameters and try again.” and the message column is blank. The wording on this page is what Microsoft Graph v1.0 returned in a lab tenant on 31 October 2026.

Reproduced in the lab

On 31 October 2026 an automated run sent these against a lab tenant, all as GET on /users:

Query	HTTP	Message
$filter=notARealProperty eq 'x'	400	Property 'notARealProperty' does not exist as a declared property or extension property.
$filter=endsWith(userPrincipalName,'onmicrosoft.com')	400	Operator 'endsWith' is not supported because the 'ConsistencyLevel:eventual' header is missing. Refer to https://aka.ms/graph-docs/advanced-queries for more information
$search="displayName:lab"	400	Request with $search query parameter only works through MSGraph with a special request header: 'ConsistencyLevel: eventual'
$top=5000	400	Invalid page size specified: '5000'. Must be between 1 and 999 inclusive.
$top=0	400	Invalid page size specified: '0'. Must be between 1 and 999 inclusive.
$filter=contains(displayName,'lab')	400	Filter operator 'Contains' is not supported.
$filter=startsWith(displayName,'lab')&$orderby=displayName	400	Sorting not supported for current query.
$orderby=mailNickname	400	Unsupported sort property 'mailNickname' for 'User'.

The control for the endsWith row was the same query with the header added, and it succeeded, which is what makes that row a measurement rather than a guess:

Query	HTTP
$filter=endsWith(userPrincipalName,'onmicrosoft.com')&$count=true with ConsistencyLevel: eventual	200

A separate test, not a control, sent $count=true with no ConsistencyLevel header. It returned 200 — and the run checked the body: @odata.count was absent.

The sorting errors do not tell you the header is the problem

Two of those rows deserve attention because of what their messages leave out.

$filter and $orderby in the same query returned Sorting not supported for current query. Microsoft’s advanced-queries page lists exactly that combination among the scenarios requiring advanced query parameters — “You can use $filter and $orderby together only with advanced queries” — but the error does not mention ConsistencyLevel at all, where the endsWith and $search errors both name it outright. Our reading: this is the same requirement reported badly, and adding the header plus $count=true is the thing to try first. The message as written sends you looking for an unsupported sort property instead.

$orderby=mailNickname returned Unsupported sort property 'mailNickname' for 'User'. — which is a sort-property problem, and names it. So the two failures look similar and have different causes, and only one of them says which.

contains returned Filter operator 'Contains' is not supported. The message names the operator and no header, and contains does not appear anywhere in Microsoft’s list of operators that advanced query parameters enable. The run sent it without the header only, so whether the header changes anything here is untested; our reading is that it does not. Use startsWith, or $search with the header, or filter client-side — both substitutions returned 200 in the lab.

$top=0 returned the same page-size message as $top=5000, so a computed $top that evaluates to zero fails like an oversized one rather than returning an empty page.

$count=true without the header is ignored, not rejected

This is the result on this page most likely to cost you time, because it does not look like a failure.

Microsoft’s advanced-query page says: “The requestor must set the ConsistencyLevel header to eventual and, except for $search, use the $count query parameter”, and lists $count as a query-string parameter among the “Query scenarios that require advanced query capabilities”. Every $count=true example on that page sets the header; the page gives no example without it and never says what happens if you omit it.

The lab answers that, with a control. GET /users?$count=true with no ConsistencyLevel header returned HTTP 200, and the run inspected the response body: @odata.count was not present. The same request with the header returned 200 and @odata.count was present. So the header is what produces the count, and without it there is no error, no warning and no count.

So the parameter is discarded rather than honoured. Code that reads @odata.count gets undefined, which renders as a blank or a zero and looks like an empty result set rather than a missing header. Compare endsWith and $search, which fail outright and name the header in the message — those are the easy cases.

Our reading: send ConsistencyLevel: eventual whenever you use $count, endsWith, $search, not, ne, $count inside a $filter, or $filter together with $orderby. Sending it when you do not need it costs nothing, and the alternative is a count that is silently absent.

$select with a bad property does not produce this error at all

In the same run, GET /users?$select=notARealProperty returned HTTP 200, with no error. A $filter on the same non-existent property returned 400 and named it.

That asymmetry is expensive in practice. A typo in $filter tells you immediately. Our reading of the $select case, from how $select works rather than from a response body the run inspected, is that you get objects without the field you asked for and your code sees undefined somewhere further downstream. Either way: if a Graph query returns objects missing a property, check the spelling and casing in $select before anything else.

Is it an attack signal?

Low. This is a developer error code. It appears while someone is writing a query and disappears when the query is right.

The only pattern worth a second look is a high volume of 400s with the “property does not exist” message from one identity, which is what property enumeration looks like — someone discovering which extension attributes a tenant has defined by asking for them one at a time. It is a weak signal: the same shape comes from a badly written sync job.

How do I fix it?

Property 'X' does not exist as a declared property or extension property. Check spelling and casing against the resource type’s property list; Graph property names are camelCase and case-sensitive in $filter. If the property is a custom extension attribute, confirm it is registered on the directory and that you are using its full name — for a schema extension that is <extensionId>_<propertyName>, and for a directory extension extension_<appId without hyphens>_<propertyName>.

Sorting not supported for current query. You are using $filter and $orderby together. Add ConsistencyLevel: eventual and $count=true before suspecting the sort property: that is what Microsoft’s advanced-queries page requires for the combination, and in the lab the same query with both added returned 200.

Unsupported sort property 'X' for 'Y'. This one really is the sort property: not every property on a resource can be sorted on. Sort on a different property, or sort client-side after fetching.

Filter operator 'Contains' is not supported. Microsoft’s advanced-query list does not include contains, so adding the header is unlikely to help and was not tested. Use startsWith, use $search="displayName:value" with ConsistencyLevel: eventual, or fetch and filter in your own code. Both substitutions were run in the lab and returned 200.

Operator 'X' is not supported because the 'ConsistencyLevel:eventual' header is missing. Add the header:

GET https://graph.microsoft.com/v1.0/users?$filter=endsWith(mail,'contoso.com')&$count=true
ConsistencyLevel: eventual

Two constraints that are easy to trip over. endsWith is supported only on mail, otherMails, userPrincipalName and proxyAddresses — adding the header will not make it work on displayName. Microsoft’s page also states that advanced queries do not support $expand — but the lab contradicts that on at least one query: GET /users?$count=true&$expand=manager with ConsistencyLevel: eventual returned 200. So the restriction is not enforced everywhere it is documented. Treat $expand with advanced parameters as something to test on your own query rather than to rule out or rely on. Microsoft’s advanced-queries page also states that in a $batch request the header goes in the JSON body of the POST rather than on the outer request.

Request with $search query parameter only works ... 'ConsistencyLevel: eventual' Same header. $search is the one case that does not also need $count.

Invalid page size specified: '<n>'. Must be between 1 and 999 inclusive. Lower $top to 999 or less and follow @odata.nextLink for the rest. Do not try to avoid paging by raising $top; the limit is the limit, and a large page is slower to produce than two small ones.

Azure AD B2C tenants do not support advanced query capabilities at all — Microsoft’s advanced-queries page says so outright — so none of the header fixes above will work there. If your tenant is B2C, the query has to be rewritten to avoid the operator.

Related

• Request_BadRequest — a malformed request rather than an unsupported query
• BadRequest — the bare form, returned when the URL or body is rejected before the query is read
• All Graph error codes