Shopify Bundle Component Availability Audit

Give this Actor your bundle bill of materials (BOM) and two dated exports of published Shopify variant availability. It tells you which bundles are blocked by an unavailable component, which became blocked between the two dates, which recovered, and which cannot be judged because component data is missing.

It works only from published true/false availability. It never reads or infers private inventory quantities.

Who it is for

Shopify merchants and operators who sell kits, gift sets or multipacks built from separate component SKUs and need a quick, repeatable check of which listings may be unsellable.

Input

Copy the prefilled sample input in the Apify Console and replace it with your data.

Field	Description
bom	Rows {bundleSku, componentSku, quantity}. Quantity is units per bundle and is shown for reference only.
bomCsv	Optional CSV text with header bundle_sku,component_sku,quantity; merged with bom.
before / after	Snapshot objects with optional label, optional ISO capturedAt, and exactly one source: rows (sku, available), csv (header sku,available) or productsJsonUrl.
includeStableBundles	Write bundles that are available in both snapshots to the dataset (default on).
maxProductPages	Page cap (1-10, 250 products each) for productsJsonUrl sources.

Availability values accepted: true/false, yes/no, 1/0, available/unavailable, in stock/out of stock, sold out.

Optional public feed source

productsJsonUrl may point to a public https://<store-domain>/products.json. The Actor validates the URL (https only, no credentials, no IP literals, only publicly routable addresses, no redirects), reads robots.txt first and stops if fetching is disallowed or robots.txt cannot be read, waits 1 second between pages, and caps pages and response size. Use only stores you are permitted to check. A live feed is a single moment in time, so save your own dated exports if you want a reliable earlier snapshot.

Output

One dataset item per bundle, plus an OUTPUT record in the key-value store with counts, snapshot metadata, warnings, component coverage and limitations.

Classifications:

• newly_blocked (high risk): all components were available or unknown before, now at least one is unavailable.
• still_blocked (medium): blocked in both snapshots.
• unverifiable (medium): nothing unavailable, but some components are absent from the later snapshot.
• recovered (low): was blocked, now no component is unavailable.
• stable_available (none).

Each item also lists blocking, newly unavailable, newly available and unknown components, how many bundles share each blocking component, and whether the bundle's own SKU is still published as available while blocked (only when the bundle SKU appears in the later snapshot).

Pricing event

The code records one bundle-audited event per bundle audited, only after results are stored. Invalid input ends the run as failed with no charge. No payable plan is configured in this repository; pricing is set separately.

Limitations

• Availability is a published flag. A "true" does not mean stock is deep, and "false" does not say why (stock-out, hidden, or policy).
• No quantity logic: a BOM quantity of 3 is not checked against anything.
• SKUs missing from a snapshot are "unknown". Duplicate SKUs in one export are merged conservatively.
• Two snapshots give one comparison. They do not establish a trend, and short-lived changes between the dates are invisible.
• Matching is by SKU (case-insensitive, trimmed). Variants without SKUs cannot be used.
• Live feed fetches check DNS before connecting but do not pin the connection to the checked address.
• No claim is made about sales impact or demand; the output is a checklist for human review.
• Not tested against real stores at the time of writing; verify results on a small bundle set first.

Local tests

Offline unit tests live in tests/ (python -m unittest discover -s tests -t .). They use no network access.