Shopify Price, Stock & Catalog Change Monitor
Under maintenancePricing
from $1.00 / 1,000 change events
Shopify Price, Stock & Catalog Change Monitor
Under maintenanceMonitor Shopify store prices, availability, and catalog changes across up to 50 stores. Detect price changes, restocks, sell-outs, new or removed products, and new variants, or export full catalog snapshots from public product feeds.
Pricing
from $1.00 / 1,000 change events
Rating
0.0
(0)
Developer
Johnn Mottin
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
13 days ago
Last modified
Categories
Share
Monitor competitor Shopify stores for price, availability, and catalog changes
Track up to 50 Shopify stores per run and receive only the changes that matter.
The Actor reads each supported store's public:
/products.json
catalog feed and can detect:
- price changes;
- restocks;
- sell-outs;
- new products;
- removed products;
- new variants.
The default monitor mode creates a free baseline on the first healthy run for each store. Later runs compare the current catalog with the saved state and write only change events.
Every monitor run also writes one free:
STORE_SUMMARY
record per store, so a successful no-change day still produces a useful monitoring result.
A separate snapshot mode exports the current product catalog instead of change events.
No Shopify account. No API key. No login. No browser automation. No LLM.
Key features
- Monitor up to 50 Shopify stores per run
- Public
/products.jsoncatalog feed - Price-change events
- Restock and sell-out detection
- New-product detection
- Removed-product detection
- New-variant detection
- Collection-specific monitoring
- Configurable minimum price-change threshold
- Free first-run baseline
- Free per-store
STORE_SUMMARY - One-shot catalog snapshot mode
- Persistent diff state
- Per-store status and diagnostics
- Result-cap state protection
- Schedule-ready for recurring monitoring
- Pay only for written events or snapshot products
Unofficial community Actor. Not affiliated with, sponsored by, or endorsed by Shopify Inc. or any monitored store. Data comes from public product feeds exposed by the monitored storefronts and remains subject to each store's applicable terms and policies.
What this Actor is for
This Actor is built for recurring competitor and catalog monitoring.
Instead of exporting the same full catalog every day, monitor mode answers questions such as:
Which competitors changed prices today?
Which products came back in stock?
Which products sold out?
Which stores launched new products or variants?
Which products disappeared from a monitored catalog?
Use it for:
- competitor price monitoring;
- e-commerce intelligence;
- brand and reseller monitoring;
- product-launch tracking;
- catalog-change analysis;
- stock-availability monitoring;
- MAP/compliance research workflows;
- dropshipping research;
- automated dashboards and alerts.
Who it's for
E-commerce merchants
Monitor competing Shopify stores and detect:
- price cuts;
- price increases;
- restocks;
- sell-outs;
- product launches;
- removed products.
Route change events to Slack, Sheets, a database, or your own automation.
Brands and suppliers
Watch reseller storefronts for:
- public price changes;
- products becoming unavailable;
- products returning to stock;
- new or removed catalog entries.
If you use the data for MAP or reseller-policy workflows, the Actor provides public catalog signals; policy evaluation remains a downstream business process.
Agencies and analysts
Monitor multiple stores in one niche and build recurring datasets around:
- catalog expansion;
- catalog contraction;
- price movement;
- product launches;
- variant growth;
- public availability changes.
Automation and data teams
Use Apify Tasks, Schedules, API calls, and integrations to send events into:
- Slack;
- Google Sheets;
- CRM systems;
- webhooks;
- databases;
- dashboards;
- internal applications.
Two operating modes
The Actor supports:
monitorsnapshot
Monitor mode
monitor is the default mode.
First healthy run
The first healthy run for a store creates a baseline in persistent state.
It does not generate fake change events for products that already existed before monitoring began.
A successful first run can therefore produce:
0 change events1 free STORE_SUMMARY
while still establishing the comparison state for future runs.
Later runs
Later healthy runs compare the current public catalog against the saved state.
Selected differences are written as:
CHANGE_EVENT
records.
Supported event types
The Actor supports:
PRICE_CHANGESTOCK_CHANGENEW_PRODUCTREMOVED_PRODUCTNEW_VARIANT
PRICE_CHANGE
Emitted when a monitored variant price changes.
The event can include:
- old price;
- new price;
- percentage change.
Use:
minPriceDeltaPct
to ignore small price movements.
STOCK_CHANGE
Emitted when the public per-variant availability flag changes.
The event includes:
stockDirection
with values such as:
RESTOCKOUT_OF_STOCK
NEW_PRODUCT
Emitted when a product appears in the current monitored catalog but was absent from the previous healthy baseline.
REMOVED_PRODUCT
Emitted when a previously monitored product is no longer present in the current healthy catalog state.
NEW_VARIANT
Emitted when a new variant appears for an existing product.
Important: availability is not inventory quantity
Shopify's public product feed exposes a per-variant:
available
boolean.
That allows the Actor to detect availability transitions such as:
available: false → true
or:
available: true → false
The public feed does not provide exact inventory quantity.
Therefore this Actor reports:
- available / unavailable;
- restock / out-of-stock transitions;
but does not claim:
- units in inventory;
- warehouse quantity;
- stock depth.
Snapshot mode
Use:
{"mode": "snapshot"}
for a one-time current catalog export.
Snapshot mode writes one:
PRODUCT
record per product.
A snapshot product can include:
- product identity;
- product title;
- product URL;
- embedded variants;
- minimum price;
- maximum price;
- public availability information.
Use snapshot mode for:
- one-time catalog exports;
- product research;
- catalog comparisons;
- initial competitor datasets;
- downstream enrichment.
Input
Daily competitor-monitoring example
{"stores": ["gymshark.com","colourpop.com"],"mode": "monitor","minPriceDeltaPct": 0}
Input fields
| Field | Type | Default | Description |
|---|---|---|---|
stores | array | required | 1–50 domains or URLs. Protocol, www, and path are normalized away. |
mode | string | monitor | monitor for change events + free summaries, or snapshot for full product exports. |
collectionHandle | string | — | Monitor a specific collection, such as best-sellers, instead of the full public catalog. |
eventTypes | array | all 5 | Any subset of PRICE_CHANGE, STOCK_CHANGE, NEW_PRODUCT, REMOVED_PRODUCT, NEW_VARIANT. |
minPriceDeltaPct | number | 0 | Ignore absolute price changes smaller than this percentage. Filtered events are not written. |
maxProductsPerStore | integer | 5000 | Per-store safety cap. Products are fetched in pages of up to 250 until the catalog ends or the cap is reached. |
maxResults | integer | 5000 | Global cap on charged output records. If a store is truncated, its diff state is not advanced. |
pageDelayMs | integer | 500 | Deliberate pacing between pages for the same store. Minimum accepted value: 250 ms. |
Example: monitor only price changes
{"stores": ["gymshark.com","colourpop.com"],"mode": "monitor","eventTypes": ["PRICE_CHANGE"],"minPriceDeltaPct": 5}
This configuration writes only price changes of at least 5% in absolute percentage terms.
Example: monitor stock changes only
{"stores": ["example-store.com"],"mode": "monitor","eventTypes": ["STOCK_CHANGE"]}
Example: monitor catalog launches
{"stores": ["example-store.com"],"mode": "monitor","eventTypes": ["NEW_PRODUCT","NEW_VARIANT"]}
Example: monitor one collection
{"stores": ["example-store.com"],"mode": "monitor","collectionHandle": "best-sellers"}
State is scoped to the store plus collection context.
Change-event output
Monitor mode writes one:
CHANGE_EVENT
record per selected detected change.
Example:
{"store": "gymshark.com","recordType": "CHANGE_EVENT","eventType": "PRICE_CHANGE","productId": "6806936649930","title": "Gymshark Training Straight Leg Leggings","url": "https://gymshark.com/products/gymshark-training-straight-leg-leggings","variantId": "39799616536778","variantTitle": "XS / Black","oldPrice": 42.0,"newPrice": 21.0,"priceDeltaPct": -50.0,"oldAvailable": true,"newAvailable": true,"detectedAt": "2026-07-30T13:00:00.000Z","previousCheckedAt": "2026-07-29T13:00:00.000Z"}
Stock-change output
A:
STOCK_CHANGE
event can include:
stockDirection
with:
RESTOCKOUT_OF_STOCK
The event is based on the public variant-level availability boolean.
It is not an inventory-count event.
Free store summaries
Every monitor run writes one free:
STORE_SUMMARY
record per store.
A summary can include:
- store status;
- products checked;
- variants checked;
- event counts;
- error information when a store fails.
This means a valid no-change store still produces a useful monitoring result.
Example:
631 products checked0 change events1 free STORE_SUMMARY
Persistent monitor state
Diff state is stored in the named key-value store:
SHOPIFY-MONITOR-STATE
with one state key per monitored store and collection context.
This state allows future runs to determine what changed.
Force a fresh baseline
Delete the relevant key from:
SHOPIFY-MONITOR-STATE
to make the next healthy run establish a new baseline.
Use this deliberately because deleting state removes the previous comparison history for that store or collection.
Result-cap state protection
maxResults limits charged output records.
If the output cap truncates a store's event set, that store's diff state is not advanced.
This prevents the baseline from moving past events that were detected but not actually written to the dataset.
Store compatibility
The Actor works with Shopify storefronts that expose the public:
/products.json
catalog feed used by this implementation.
If that public feed is not available, the store cannot be monitored through this Actor's current method.
Possible controlled statuses include:
NOT_SHOPIFY_OR_HEADLESSSTORE_PASSWORD_PROTECTEDSTORE_BLOCKED
Headless or unsupported storefronts
Some Shopify stores use headless or custom storefront architectures and do not expose the public feed expected by this Actor.
Those stores can be reported as:
NOT_SHOPIFY_OR_HEADLESS
rather than producing fabricated catalog data.
Password-protected stores
If a store requires a password before public catalog access, the Actor can report:
STORE_PASSWORD_PROTECTED
The Actor does not log in or bypass storefront access controls.
Explicit blocks
If a store returns blocking responses such as:
403430
the Actor can report:
STORE_BLOCKED
The Actor does not rotate proxies or use evasion techniques against an explicit block.
One failed store does not kill the batch
An unsupported, blocked, or unavailable store does not automatically stop healthy stores in the same run.
The batch fails globally only when no store completes successfully, using:
ALL_STORES_FAILED
This allows mixed store lists to continue processing valid storefronts.
Run health and diagnostics
Operational information is written to:
STATS
The statistics can include:
- per-store status;
- pages fetched;
- products processed;
- events by type;
- HTTP counters;
- field-completeness health checks;
- warnings.
Failures and diagnostic errors can be written to:
ERRORS
Catalog pagination
The Actor reads the public product feed in pages of up to:
250 products
per request.
Pagination continues until:
- the catalog ends;
maxProductsPerStoreis reached;- another controlled stop condition occurs.
Use:
maxProductsPerStore
to control large-store processing.
Scheduling
Monitor mode is intended for recurring use.
A daily cadence is a practical default for competitor price and availability monitoring.
Why cadence matters
The Actor compares two stored healthy states.
If a product changes price twice between monitor runs, the next event can only describe the difference between:
- the previous stored state;
- the current observed state.
Intermediate changes that occurred entirely between runs cannot be reconstructed automatically.
For that reason, more frequent runs provide finer change resolution.
Recommended daily setup
- Save your store list as an Apify Task.
- Run it once to establish free baselines.
- Go to Console → Schedules → Create schedule.
- Add the Task.
- Choose a daily schedule.
- Route events and summaries into your downstream workflow.
Example daily 6:00 AM cron:
0 6 * * *
Possible destinations include:
- Slack;
- Google Sheets;
- CRM systems;
- databases;
- webhooks;
- dashboards;
- internal e-commerce intelligence systems.
The Actor runs in Apify's cloud, so your local computer does not need to remain on.
Example competitor-monitoring workflow
Input:
{"stores": ["competitor-one.com","competitor-two.com","competitor-three.com"],"mode": "monitor","eventTypes": ["PRICE_CHANGE","STOCK_CHANGE","NEW_PRODUCT","REMOVED_PRODUCT"]}
First run
The Actor:
- processes each supported public catalog;
- creates the baseline;
- writes free store summaries;
- does not create fake events from the existing catalog.
Later runs
The Actor can emit events such as:
PRICE_CHANGESTOCK_CHANGENEW_PRODUCTREMOVED_PRODUCT
You can then route those events to another system for:
- alerting;
- reporting;
- competitor analysis;
- pricing review;
- catalog research.
MAP and reseller-monitoring workflows
Brands and suppliers can use public price-change events as an input to their own reseller-monitoring process.
Example workflow:
- monitor authorized or known reseller stores;
- collect public price changes;
- compare current prices with your own policy or pricing rules;
- route possible exceptions for internal review.
The Actor itself does not decide whether a price violates MAP or another commercial policy.
It provides structured public pricing signals for downstream evaluation.
Pay only for written events or snapshot products
This Actor uses Pay Per Event pricing.
In monitor mode, you are billed for change-event records actually written.
The free:
STORE_SUMMARY
records are not billed as change events.
The first healthy baseline does not create fake billable change events.
Events removed by:
eventTypes;minPriceDeltaPct;maxResults
are not written as charged change events.
In snapshot mode, billing is based on product records actually written.
The Pricing tab on the Actor page is always the authoritative source for current prices and any run-start fee.
Cost-control options
Use:
collectionHandleeventTypesminPriceDeltaPctmaxProductsPerStoremaxResults
to control run size and written records.
Examples:
Ignore tiny price movements
{"minPriceDeltaPct": 5}
Limit each store
{"maxProductsPerStore": 1000}
Monitor only one collection
{"collectionHandle": "best-sellers"}
Request footprint
Catalog pages contain up to approximately:
250 products per page
The Actor uses:
pageDelayMs
to pace requests between pages for the same store.
Default:
500 ms
Minimum:
250 ms
Large catalogs require more pages and therefore more source requests.
Honest limits
Only storefronts exposing the expected public feed
This Actor depends on the public:
/products.json
catalog endpoint.
Stores that do not expose that feed cannot be monitored through the current implementation.
Availability, not quantity
The public feed exposes whether a variant is available.
It does not expose exact stock quantity.
Diff quality depends on cadence
Only changes between recorded healthy states are observable.
Multiple intermediate changes between runs can collapse into one final diff.
First run is baseline only
A store cannot produce a meaningful change event until there is a previous healthy state to compare against.
Some stores block or protect access
The Actor reports controlled statuses instead of bypassing store restrictions.
Public catalog data can change
Product feeds, storefront behavior, and Shopify implementations can change over time.
FAQ
Do I need a Shopify account?
No.
Do I need a Shopify API key?
No.
Does the Actor log in?
No.
Does it use browser automation?
No.
What data source does it use?
The current implementation reads the public Shopify storefront:
/products.json
feed when the store exposes it.
How many stores can I monitor?
Up to:
50
stores per run.
Can I provide full URLs?
Yes.
The Actor normalizes domains and URLs by removing protocol, www, and paths.
Can I monitor one collection?
Yes.
Use:
collectionHandle
What is the default mode?
monitor
What happens on the first monitor run?
The first healthy run creates a free baseline.
No comparison events are possible until a later healthy run.
What happens when nothing changes?
Each successfully monitored store still gets one free:
STORE_SUMMARY
record.
Can I export the full catalog?
Yes.
Use:
{"mode": "snapshot"}
Can I monitor only price changes?
Yes.
{"eventTypes": ["PRICE_CHANGE"]}
Can I ignore small price changes?
Yes.
Use:
minPriceDeltaPct
Can I detect restocks?
Yes.
A variant changing from unavailable to available can produce:
STOCK_CHANGEstockDirection: RESTOCK
Can I detect sell-outs?
Yes.
A variant changing from available to unavailable can produce:
STOCK_CHANGEstockDirection: OUT_OF_STOCK
Does it show exact inventory quantity?
No.
The public feed only exposes the availability boolean used by this Actor.
Can I detect new products?
Yes.
Use:
NEW_PRODUCT
Can I detect removed products?
Yes.
Use:
REMOVED_PRODUCT
Can I detect new variants?
Yes.
Use:
NEW_VARIANT
What happens if the store is headless or unsupported?
It can receive:
NOT_SHOPIFY_OR_HEADLESS
What happens if the store is password-protected?
It can receive:
STORE_PASSWORD_PROTECTED
What happens if the store blocks the request?
It can receive:
STORE_BLOCKED
The Actor does not attempt to evade an explicit block.
Where is diff state stored?
In:
SHOPIFY-MONITOR-STATE
with state scoped by store and collection context.
Can I reset the baseline?
Yes.
Delete the relevant state key from SHOPIFY-MONITOR-STATE.
What am I charged for?
Change events written in monitor mode or product records written in snapshot mode.
STORE_SUMMARY records are free.
Always check the Actor's Pricing tab for current prices and run fees.
Can I schedule it?
Yes.
Daily scheduling is a practical starting point for competitor price and availability monitoring.
Is this affiliated with Shopify?
No.
This is an unofficial community Actor and is not affiliated with, sponsored by, or endorsed by Shopify Inc. or any monitored store.
Part of the JM Forge suite
Also from the same developer:
-
Amazon Product Search Scraper — Extract Amazon product listings, prices, discounts, ratings, review counts, ASINs, and images across seven marketplaces.
-
Amazon Best Sellers & Product Rank Scraper — Extract ranked Amazon Best Sellers lists with ASINs, prices, ratings, review counts, images, and product URLs in the US and UK.
-
Steam Game Price, Discount & Review Monitor — Monitor Steam app IDs for price changes, discounts, release-state changes, and review movement without login or API keys.
Support
Report issues in the Issues tab of this actor — I respond within 24h. Feature requests welcome.