Microsoft Graph g-raph (giraffe) - the spirit animal of Microsoft Graph

Graph API throws “$count is not currently supported.” when you KNOW it’s supported?

2 min read.

Hey, another funny case. “Funny” as in “the error message is misleading and googling didn’t really help”, but also as in “a colleague knew the answer right off the bat because he already fixed it in another project”.

This time the documentation was in fact there, it just wasn’t there to be found.

Anyway – what have I broken this time?


Table of Contents

When you’re calling Graph API with both $filter and $count, for example like this:$count?$filter=assignedLicenses/any(x:x/skuId eq 189a915c-fe4f-4ffa-bde4-85b9628d07a0)

Instead of the expected number of found items, you get result like this even though you’re pretty sure your syntax is just peachy:

    "error": {
        "code": "Request_BadRequest",
        "message": "$count is not currently supported.",
        "innerError": {
            "date": "2020-12-01T19:10:25",
            "request-id": "645f1148-040e-4cf9-8aed-7e8acc88f4bc",
            "client-request-id": "c35759ce-2d8a-56f8-032c-1bc65e612b5d"

“$count is not currently supported.” – really? I happen to KNOW it is supported for filtered user collections on Graph API.

.. so what gives?


Well, once again, the solution turned out to be simple.

Some calls to Graph API with $count (and $search) require consistency level to be set to “eventual”. In Graph Explorer, that’s done like shown below:

How to add a request header in Graph Explorer?
How to add a request header in Graph Explorer?
  • Key: “consistencylevel”
  • Value: “eventual”

Or in C#, it’s done like this:

using (var request = new HttpRequestMessage(HttpMethod.Get, url))
	request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", yourAccessToken);
	request.Headers.Add("consistencylevel", "eventual");

	var result = httpClient.SendAsync(request).GetAwaiter().GetResult();

	// your code here

And with that, you should be good!

Graph Explorer Response preview
Graph Explorer Response preview

But what is “eventual consistency”? Microsoft defined it like this a while back:

What is eventual consistency?

Azure Active Directory stores multiple copies of data to handle large read volume and provide high availability. When data is updated, the change will eventually be applied to all the copies.

$search and $count queries require the client to opt-in for eventual consistency by setting the header ConsistencyLevel = eventual.

For example, this means that when you add a user, you need to wait for all the copies to be updated to search or count them.


The credit for this one actually goes to my coworker Marcin Wojciechowski, who figured out the issue but doesn’t want to blog about small topics like this :)

He shares his more thorough articles about Microsoft 365 / Azure -related topics at his blog – check it out!

5 13 votes
Article Rating
Notify of
most voted
newest oldest
Inline Feedbacks
View all comments