Can a Shopify app audit your whole catalogue if it only checks the first 250 products?
If your store has more than 250 products, a report that says “catalogue audited” needs one follow-up question: did it actually reach the end?
Two hundred and fifty is a Shopify API limit per request. It is not the size of a catalogue Shopify considers complete.
That distinction is easy to miss. An app can make one request, receive 250 products, inspect them carefully, and still leave the rest of your catalogue untouched.
We ran into this while building our own `llms.txt` builder. Shopify’s `/products.json` endpoint returns at most 250 products per page. At first glance, the response can look like a full catalogue read. It is not. We had to handle pagination so the builder could continue beyond the first page.
This is not just a developer detail. It changes whether you can trust an audit.
What the 250-product limit actually means
Shopify’s API returns products in batches. In the REST Admin API, the default batch is 50 products. An app can request up to 250 with a URL like this:
`GET /admin/api/{api_version}/products.json?limit=250`
If your store has 180 products, one request can be enough.
If your store has 700 products, one request covers only the first part. The app needs more requests before it can assess titles, descriptions, variants, metafields, missing fields, or any other product-level check across the catalogue.
The important word is per page.
A page is one batch of results. It is not the whole result set.
How an app reaches the next products
With the REST Admin API, Shopify can return a `Link` header with a next-page URL. That URL contains a cursor called `page_info`.
The app should follow that next-page URL, read the next batch, and repeat the process. When Shopify returns only a previous-page link, the app has reached the final page.
A simplified version looks like this:
1. Request up to 250 products. 2. Read those products. 3. Check whether Shopify supplied a next-page link. 4. If it did, request that page. 5. Continue until there is no next page.
The cursor matters. An app should use Shopify’s next-page URL rather than trying to construct page numbers itself.
Shopify now treats the REST Admin API as legacy. Its current direction is GraphQL Admin API for apps and integrations. But the underlying problem is the same: one request is a batch, not necessarily a catalogue.
The GraphQL version has the same trap
In GraphQL, an app queries a `products` connection. It can ask for up to 250 products in one request using `first`.
The response includes `pageInfo`, including:
- `hasNextPage`, which says whether more products exist
- `endCursor`, which identifies where the next request should begin
An app that wants the full catalogue should request the next batch using that cursor. It keeps doing so until `hasNextPage` is `false`.
Say your store has 620 products. A complete read might take three batches: 250, 250, then 120. An app that reads only the first batch has checked roughly the first third. It has not checked the catalogue.
This can lead to quiet gaps. A store may have older products with thin descriptions. It may have items added through a different workflow. It may have seasonal products that sit later in the returned list. If the audit stops early, those products may never appear in the report.
Bulk queries are often the better route
Shopify also offers GraphQL bulk operations for larger reads.
Instead of requesting page after page, an app can run a bulk query against products. Shopify prepares the result as a downloadable JSONL file. JSONL means one JSON record per line, which makes it practical to process large result sets without holding everything in one normal API response.
For a large catalogue, this can be simpler and safer than ordinary page-by-page retrieval.
Shopify’s own documentation recommends bulk operations when an app needs to retrieve larger volumes. Ordinary GraphQL pagination also has a documented 25,000-object cap for arrays of objects, including count queries. That does not mean every store needs a bulk job. It does mean an app should have a plan beyond “ask for 250 and stop.”
What a complete audit should be able to show you
You do not need to inspect API headers to ask a sensible question.
When an app says it audited your catalogue, look for evidence of scope. In under a minute, check whether its report tells you:
- How many products it checked
- Whether that count matches the number of products you expected
- When the audit ran
- Whether the audit was limited by a plan, filter, product status, or collection
- Whether it processed results in pages or used a bulk operation
The first item is the quickest check. If your store has more than 250 products and the report says it checked 250, the audit was not whole-catalogue.
There may be a valid reason for that limit. An app may offer a sample audit. It may deliberately check only published products. It may exclude drafts or archived products. It may be designed for a specific collection.
That is fine when it is stated plainly.
The problem is not batching. Batching is normal. The problem is calling a partial batch a complete audit.
A practical test for app makers and merchants
If you build or review an audit workflow, use a store with more than 250 products.
Then make one small, easy-to-find change to a product that sits beyond the first batch. For example, add a distinctive phrase to a product title or leave one description field empty. Run the audit again and see whether it finds that product.
This does not prove every part of the audit is correct. But it does test the most basic claim: whether the process went past the first page.
For merchants, the simpler version is to compare counts. If you know your catalogue contains more products than the report processed, ask what was excluded and why.
For developers, treat pagination as part of the audit itself. Do not bolt it on after the checks work. The audit cannot make a whole-catalogue claim until the retrieval layer knows where the catalogue ends.
The answer
An app can process products in batches of 250. That is expected.
But if it retrieves the first 250 and stops, it has not audited your whole Shopify catalogue. It needs to follow every available page, or use a bulk operation, before making that claim.
The quiet next step is to open the last catalogue audit you received and compare its product count with your store. If the numbers do not match, ask whether the tool paginated through the full result set.