Back to Blog
ShopifyEcommerceApify

Your Weekly Shopify Export Needs a History You Can Explain

Build a repeatable Shopify export workflow with Apify, retained snapshots and coverage checks before interpreting missing rows as product changes.

Anas Nadeem
4 min read

You have a useful supplier catalog file. The next request is easy to imagine: collect those URLs again next week and tell us what changed.

That is where a one-off export becomes a data workflow. If the second run has fewer rows, did products disappear, did the scope change, or did collection stop early?

I built the Shopify Product Scraper on Apify alongside Catalog Prep for the repeatable collection job. It takes supplied public store, collection, and product URLs and returns catalog data with files that explain coverage.

Here is how I would build on that result without turning every collection problem into a false alert.

Prove one small input before scheduling it

Begin with a supplied public URL and five products. This documented example illustrates the input; current store availability can change:

{
  "startUrls": [{ "url": "https://silverpawdog.com/" }],
  "maxProductsPerTarget": 5,
  "maxProducts": 5,
  "exportFormats": ["csv", "xlsx", "json", "zip"]
}

Inspect the dataset and export links. Compare a few returned products with the source, including one with several variants. A five-product cap can produce a successful process and explicitly partial catalog coverage. That is a useful test when you keep the qualification.

The actor has its own limits and Apify charges. Catalog Prep extension Pro does not include those runs. For an interactive browser task, use the extension guide.

Store products and variants as different levels

The normalized dataset keeps products with nested variants and images. The catalog CSV has one row per returned variant. The actor's workbook separates Products, Variants, Images, and Coverage.

Keep product and variant identifiers as text, with their relationships intact. A reused SKU is not a reason to merge different variant identities.

In the retained 28 October 2026 Silver Paw public-feed audit, 89 products had 267 variants and 264 distinct nonempty SKUs. That observation does not describe today's complete catalog, but it exposes the flaw in treating every SKU as a unique row identity.

Save each snapshot's collection context

For every run, retain the source URL, requested scope, observation time, configured limits, returned counts, status, and available warning or issue details. Keep the original files as well as your normalized working table.

That context helps you answer the next question without guessing.

Later observationFirst check
Fewer product identitiesSame source scope and adequate coverage?
Fewer variant rowsReturned option coverage and limits?
Price changedSame identity and currency context?
Availability changedSource flag changed, or field now missing?
No rowsObserved empty scope, blocked access, or failed retrieval?

A blocked or partial capture belongs in a review path. Its missing rows should not automatically become a “supplier removed these products” notification.

Keep currency uncertainty visible

Public prices may arrive without confirmed currency. Preserve the source amount and currency status. The actor can accept an operator currency assertion after you verify it, but that labels the value rather than converting or independently confirming it.

Keep currencies and source locales separate before comparing snapshots. Do not turn a page hint or familiar currency symbol into an unsupported assumption about the feed.

Public availability is similarly limited evidence. It describes the source's exposed flag, not stock quantity, sales, or revenue.

Schedule collection, then add comparison logic

Save the verified input as an Apify task and use Apify schedules for repeated collection. An API integration requires your Apify token, not a Shopify Admin key for the public-source workflow.

The schedule runs the task again. Historical storage, matching identities, reviewing coverage, and producing change alerts remain explicit steps in your own system.

Compare equivalent scopes and preserve unknown outcomes. Where an identity is absent from a trustworthy later snapshot, describe what you observed and the interval between successful captures. The exact time or commercial reason for the change may remain unknown.

Start with a comparison you can defend

Run the Shopify actor on a small scope, inspect the coverage files, and save the snapshot. On the next run, compare a few known identities manually before building an alert around the result.

Use the catalog-quality worksheet for the file review. Source exports still need destination mapping and permissions review before importing products elsewhere; this actor does not write to Shopify.

When the question is simply one collection in front of you, Catalog Prep for Chrome offers the local path. Use the actor when the work needs a repeatable run and keep the evidence that makes that run understandable.