Documentation says that this query limited to 10000 products:
Not sure what’s suggested to do for larger stores. Loading all products just to get the count seems inefficient. And the REST API didn’t had this limitation, I just tried getting products count on store with 1.5M products and it worked fine.
I can’t help with this one, but we certainly had a lively and long thread all about this some time ago. The fun never stops does it! My favorite aspect is the resolution you just pointed out that was thrust upon us as the result a few months ago.
And we cannot know this unknown number, because ???
It reminds me of the same problem Shopify has had for nearly 20 years now. No matter your store, whether you have 51 or 501 or 5000001 products in it, Shopify never shows you that number.
I think the only option, using GraphQL, is to query products and use pageInfos hasNextPage and endCursor to paginate the responses and accumulate the total amount.
Also, if a manual check up can do, you can use https://admin.shopify.com/store/{{shop_name}}/products/count.json, but you probably already know that.
Limit counting up to 10k items. Shopify, are you joking? It shameful to even have this kind of a limit. Now we need to run a binary partitioning of data on timestamp to get a real count? Making 10, 20, 30, 100 queries?
For now it’s best to use REST as it seems to work. GraphQL is not finished, please don’t remove REST!
And exactly the same issue happens with GraphQL orders count (‘ordersCount’ query). It has also a limit of 10000.
We’re looking at options to increase the limit beyond 10K. One of the challenges is data cuts across multiple DBs + filter support.
Question: Do your use cases require exact counts with filters? Eliminating filters should make it easier to support much larger counts with EXACT precision (we would still support filters, just with less accuracy)
Hi Darius_Gai,
in our case, we use a simple filter with REST API: “published_status=published”.
Anyway, comparing with current GraphQL options, filters with non exact precision or even no filters would be a great advance.
Thanks.
Adding in here, its ridiculous that we have this 10,000 limit.
I’ve posted about productVariantCount too, not sure if this imposes the same limit.
FYI, Liam has just confirmed there isn’t a limit for productVariantsCount, so I see no reason to have productsCount updated to have no limit.
Hi Darius,
We are facing a similar issue where it’s crucial for us to obtain the exact total product count without any filters. Our app’s subscription plans are directly based on this value, so moving from REST API to the new approach is challenging if we can’t accurately determine this count. Currently, we’re using the REST API for this purpose, and this change impacts our core functionality.
How is obtaining exact overall counts supposed to work in the new API? Specifically, for products, and ideally also for metafields of a given entity?
Any updates on this? Pretty strange that productVariantsCount is not limited while productsCount is.
This limit is also imposed on orders too 
Returns the count of orders for the given shop. Limited to a maximum of 10000
I would like to propose adding a totalCount field for list resource queries in the Shopify API. For example, a query like "query products(first: 1) { totalCount }" would allow developers to directly retrieve the total count of resources such as products.
This feature would greatly simplify development workflows and address issues currently faced with limitations in APIs like productCounts. It would provide an efficient and straightforward way to access this critical information without requiring additional filters or complex workarounds.
Ideally, this functionality could be implemented for all similar queries, including orders and other APIs, to ensure a consistent and streamlined experience across the platform.
Try explaining to people why it’s hard to count rows across distributed databases.
The solution is to loop through paginated products and aggregate the count. Either you do the processing or expect Shopify to do it. Yes it would be nice, but is it really needed? Honestly there are more important things Shopify should spend time on.
If you think you need an accurate total count from a single query, I’d start by looking at what is it you’re trying to do.
Why don’t you create a use case to get the total count through pagination and block plan selection until that’s ready?
Even if Shopify could return the total count in a single query, how would you know product couldn’t didn’t change 2min later?
You need to have a flow that will raise warnings when your system detects changes to total product count. This flow needs to be triggered asynchronously and periodically anyway, what do you care if the aggregated count calculated returned in every second, every 10 minutes or every hour. Will you really spend resources on check-in product count all day everyday?
Think flows and states.
Why not show a “checking plan…” status or a more detailed message like “Counting products … XX,XXX” using RPC or whatever so the user sees what’s going on.
We’re dealing with cloud applications here, there’s no guarantee the Graphql API is even able to respond to your query right now. Enqueue a task to calculate the product count and move on until the relevant application use case completes, the inform the user they can continue.
What if the user closes their browser while your fetching the product count?
Hi Evaldas,
Our use case differs as our app’s pricing is directly tied to the total count of entities, making this data crucial for verifying plan limits and charging customers fairly. We’ve optimized with caching to reduce load on Shopify, but an endpoint that provides the exact total count remains essential for transparency and functionality.
If REST API offers this, why not GraphQL? Transitioning APIs shouldn’t require rebuilding our pricing logic. Adding this feature would resolve many issues for developers relying on accurate counts.
May I ask how often you fetch product counts?
The frequency of fetching product counts depends entirely on how often clients initiate tasks in our app, typically for data export/import. These actions are client-driven and not automated, so there is no consistent periodicity. A client might not perform these tasks at all in a day, or they could trigger them multiple times depending on their specific needs at that moment.
@Darius_Gai We also use it on the subscription page. No filter is needed here. Some customers have over 1 million products. Making users wait for minutes on the pricing page to get the bulkOp result creates a poor onboarding experience. We also fetch counts daily to ensure proper upgrades or downgrades if necessary.
Could you first provide the GraphQL equivalents of the operations on the REST page in a clear manner, before moving on to complex cases, so we can complete our transition?