A Count Endpoint Returned 404. The Store Was Not Empty.
A dated Shopify source audit found 89 products after a count endpoint returned 404. Here is why unknown, zero and partial need different states.
An unavailable number is a product-design problem when the interface is expected to show a count.
During a retained check of Silver Paw's public Shopify source on 28 October 2026, the count endpoint returned HTTP 404. Other public source responses contained products. Reporting zero would have converted a failed counting path into a false claim about the catalog.
This is one of the details behind Catalog Prep's scope and count states. The interesting part is how to represent what the tool knows without making up the rest.
Start with the actual observations
The retained whole-store feed returned 89 unique products and 267 variants. A 250-product request returned those 89 records, followed by an empty page. A separate 50-product pagination path returned 50, then 39, then zero.
The product identities matched across those observed paths. The audit also recorded 264 distinct nonempty SKUs, which is a separate count from variant identities.
The feed counts were checked against saved source bytes. The 404 is recorded in the dated audit note; a raw response for that endpoint was not retained. They do not guarantee current contents, universal Shopify endpoint behavior, or another tool's result.
The collection was a different set
The all-products-xx collection had 85 products and 259 variants in the checked feed. Its visible page count was 85. The public whole-store feed contained 89 products.
It would have been tempting to use the collection's visible number as a convenient store total. That would have hidden the scope difference.
Collection names, product counts and unique store identities need to remain separate. Products can also belong to several collections, so adding collection totals is not generally a unique-product count.
Three states the interface should not collapse
| State | What it means for the reader |
|---|---|
| Observed zero | The relevant source reported or yielded no products under the checked conditions |
| Unknown | The tool could not establish that count |
| Lower bound | A bounded scan found at least this many identities but did not establish the total |
A successful count path can add evidence. An unsuccessful one should preserve uncertainty rather than erase it with a default value.
Catalog Prep's discovery can use public count metadata or bounded unique-ID scans. Unknown totals stay qualified, and incomplete scans can show a lower bound. Discovery itself is bounded; it is not an unrestricted inventory of every private or public merchant record.
Counts should guide capture, not rewrite its result
A selected collection needs its own expected count when available. The current page's total should not silently become the expected count for another collection selected inside the popup.
When capture ends, compare the requested scope, observed records, configured limits and count evidence. Preserve a partial result as partial if the evidence calls for that qualification.
This gives the person using the file something useful to investigate. A confident but unsupported total makes the interface simpler while making the export harder to explain.
The same lesson appears in other fields
An absent SKU is not an invalid product identity. A missing currency is not proof of the page's displayed currency. An unavailable response is not a successful empty dataset.
These distinctions are small individually. Together, they determine whether the output preserves what the source actually exposed or substitutes assumptions for gaps.
The founder decision here is to keep those gaps visible. It does not make every store accessible, and it does not turn public availability into actual inventory quantity.
Check it on the task you have
Open a supported public storefront in Catalog Prep. Compare the website and current-collection choices, inspect any count qualifications, and capture a small scope with the popup open.
Then read the downloaded manifest beside the workbook. The collection export guide explains how to keep those scopes separate. You should be able to describe which scope was collected and what remains uncertain.
If you report a mismatch, keep the source URL, selection, capture time, status and one example identity. That makes the next investigation specific instead of turning it into another unexplained rerun.