Compare Shopify product variant changes with RapidAPI and a data table

Quick overview

Compare price and availability changes for variants of one known public Shopify product. Save the latest complete report in an n8n Data Table and use it on the next manual run. This free workflow uses a paid, publisher-owned RapidAPI service.

How it works

1. A manual execution validates the product, currency, date and explicit spending consent.
2. It reads the latest complete report from a Data Table, reserves one attempt and the request's recovery key, and verifies that reservation before calling the API once.
3. It validates the full response, saves it together with the updated pilot state and reads it back before returning success.
4. The first success establishes a baseline; later successes include variant-level changes.
5. Errors preserve the prior report.
6. No scheduled monitoring or alerts are included.
7. Only one execution and one workflow copy may use the history row.

Setup

1. Use n8n2.40.7 or a compatible release supporting Data Table create/get/upsert. Enter a known public product URL, its expected currency and a stop date within 14 days.
2. Add your RapidAPI key as an HTTP Header Auth credential named x-rapidapi-key and select it on the HTTP node. Review current pricing and the complete setup note before enabling spending consent.
3. Run one execution at a time, one workflow copy, without manual history edits. Stop at 14 reserved attempts or the saved date; follow the note's exact recovery procedure.

Additional info

EcomOpsKits publishes the linked paid API:
https://rapidapi.com/ecomclosekit/api/shopify-variant-price-and-availability-diff

The USD0.01/request tariff is the October4 publication snapshot, not a current
buyer quote; bandwidth/other charges and n8n hosting are separate. Replays/errors
may bill. The workflow counter is not a billing cap or concurrency lock. Full
product URL/previous report data is transmitted to RapidAPI/Cloudflare/Apify;
no retention period is promised. Only one public product/source/currency and
1–249variants are supported. This is a latest-report comparison pilot, without
sales/inventory inference, currency conversion, schedules or alerts. Free direct
Shopify JSON/code solutions are possible; this API is a convenience choice.

On interruption/error before commit, inspect the saved row and prior execution.
If recovery is appropriate, enable recoverPendingRequest and run the full
workflow with the same credential/consumer. It reuses the exact saved body/key,
consumes another slot and may bill. A cached provider error remains an error;
recovery does not promise a fresh observation. An uncertain backend start may
need provider reconciliation. Never use native Retry execution, partial
Execute step on HTTP/save nodes, a fresh key or reset history to recover:
these can bypass the reservation or create another billable request. After a
successful commit, pending is already cleared; explicit recovery then refuses
another call. Disable recovery only when deliberately starting a new observation.