Catalog Reconciler

Supplier and store catalogs change over time, but spotting exactly what changed between two snapshots can mean maintaining custom comparison code. Catalog Reconciler compares two product catalog snapshots and returns clear records for price changes, newly added products, discontinued products, and unchanged matches—without building that comparison logic yourself.

Typical uses include reconciling supplier feeds, synchronizing e-commerce catalogs, and passing product changes into automated monitoring workflows. Each successfully completed comparison is priced at $0.10 on Apify.

{
  "matchBySku": true,
  "catalogA": [{"sku": "ITEM-001", "price": 19.99}],
  "catalogB": [{"sku": "ITEM-001", "price": 17.99}]
}

Ready to reconcile your catalogs? Provide two JSON snapshots in the Actor input and run Catalog Reconciler. Enable SKU matching only if both catalogs share the same SKU namespace.

Input

{
  "matchBySku": true,
  "catalogA": [{"sku":"LAPTOP-001","name":"Laptop Pro 15","price":899}],
  "catalogB": [{"sku":"LAPTOP-001","name":"Laptop Pro 15","price":849}]
}

Each catalog must be an array of JSON objects. Products may contain gtin, ean, sku, name, and price (other source fields are preserved in output). GTIN/EAN values are normalized by removing spaces and hyphens and must contain 8, 12, 13, or 14 digits. If both are present, they must agree. SKU matching is disabled by default and should only be enabled when both feeds share a SKU namespace. Names are not matching identifiers. Maximum combined catalog size: 10,000 records.

Prices are compared using decimal arithmetic. Both catalogs are assumed to use one common currency; no currency detection or conversion is performed.

Results

Every dataset item has productKey, status, productA, and productB; priceDifference is present for price changes and equals price B minus price A. Statuses are added, removed, price_changed, unchanged, or invalid_price. The Actor also stores a SUMMARY object in the default key-value store, including totals, per-status counts, and per-catalog record errors.

Pay-per-event billing

On Apify, each successfully persisted comparison is charged once as the comparison-completed event at $0.10. The run's maximum charge must allow at least one event. The Actor checks its pricing and remaining run budget before reconciliation, then writes all dataset results and SUMMARY before requesting the charge. A rejected or failed charge causes the run to fail rather than being reported as a paid success; persisted output may still be present if the charge request fails after persistence. Charging and storage persistence are separate platform operations, so a successful comparison cannot be guaranteed to be charged if the charge request fails after persistence.

Configure pay-per-event pricing in Apify Console with comparison-completed priced at $0.10. Disable/remove the apify-actor-start and apify-default-dataset-item synthetic events to avoid startup and per-dataset-item charges. The Actor checks for these synthetic events and refuses to compare when a nonzero price is configured. The startup event, if enabled, may already be charged by Apify before Actor code can perform this check, so it must be disabled in Console before running. Apify's Console pricing settings are separate from the source repository and must be configured by the Actor owner.

Duplicate identifiers and invalid/conflicting GTIN/EAN values are reported in summary errors and excluded from matching. Records without identifiers are reported as errors. SKU matching is blocked when both records have conflicting GTINs. Invalid or missing prices on matched products result in invalid_price. Invalid top-level structure fails the run with a clear validation error.

Run

On Apify, provide the JSON in the Actor's Input tab and start a run. For local development, install the requirements and run apify run (this initializes Apify local storage); place the input in storage/key_value_stores/default/INPUT.json. Tests can be run with python -m pytest.

Limitations

No fuzzy/name matching, scraping, enrichment, currency conversion, or historical price storage. Input catalogs must be supplied directly and share a common currency. Identifier equivalence beyond exact normalized GTIN/EAN or explicitly enabled SKU is not inferred.