Shopify Price, Stock & Catalog Change Monitor avatar

Shopify Price, Stock & Catalog Change Monitor

Under maintenance

Pricing

from $1.00 / 1,000 change events

Go to Apify Store
Shopify Price, Stock & Catalog Change Monitor

Shopify Price, Stock & Catalog Change Monitor

Under maintenance

Monitor 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

Johnn Mottin

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

13 days ago

Last modified

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.json catalog 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:

monitor
snapshot

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 events
1 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_CHANGE
STOCK_CHANGE
NEW_PRODUCT
REMOVED_PRODUCT
NEW_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:

RESTOCK
OUT_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

FieldTypeDefaultDescription
storesarrayrequired1–50 domains or URLs. Protocol, www, and path are normalized away.
modestringmonitormonitor for change events + free summaries, or snapshot for full product exports.
collectionHandlestringMonitor a specific collection, such as best-sellers, instead of the full public catalog.
eventTypesarrayall 5Any subset of PRICE_CHANGE, STOCK_CHANGE, NEW_PRODUCT, REMOVED_PRODUCT, NEW_VARIANT.
minPriceDeltaPctnumber0Ignore absolute price changes smaller than this percentage. Filtered events are not written.
maxProductsPerStoreinteger5000Per-store safety cap. Products are fetched in pages of up to 250 until the catalog ends or the cap is reached.
maxResultsinteger5000Global cap on charged output records. If a store is truncated, its diff state is not advanced.
pageDelayMsinteger500Deliberate 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:

RESTOCK
OUT_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 checked
0 change events
1 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_HEADLESS
STORE_PASSWORD_PROTECTED
STORE_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:

403
430

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;
  • maxProductsPerStore is 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.


  1. Save your store list as an Apify Task.
  2. Run it once to establish free baselines.
  3. Go to Console → Schedules → Create schedule.
  4. Add the Task.
  5. Choose a daily schedule.
  6. 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_CHANGE
STOCK_CHANGE
NEW_PRODUCT
REMOVED_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:

  1. monitor authorized or known reseller stores;
  2. collect public price changes;
  3. compare current prices with your own policy or pricing rules;
  4. 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:

collectionHandle
eventTypes
minPriceDeltaPct
maxProductsPerStore
maxResults

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_CHANGE
stockDirection: RESTOCK

Can I detect sell-outs?

Yes.

A variant changing from available to unavailable can produce:

STOCK_CHANGE
stockDirection: 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:

Support

Report issues in the Issues tab of this actor — I respond within 24h. Feature requests welcome.