Shopify Competitor Price & Stock Monitor | WooCommerce avatar

Shopify Competitor Price & Stock Monitor | WooCommerce

Pricing

from $3.00 / 1,000 observed products

Go to Apify Store
Shopify Competitor Price & Stock Monitor | WooCommerce

Shopify Competitor Price & Stock Monitor | WooCommerce

Monitor Shopify competitor prices, stockouts and restocks with automatic rolling comparisons and optional change webhooks. Includes WooCommerce catalog snapshots, variant details where published, CSV exports and coverage reports. $3/1,000 product observations + $0.001/run.

Pricing

from $3.00 / 1,000 observed products

Rating

0.0

(0)

Developer

Saahir Sultan

Saahir Sultan

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

12 hours ago

Last modified

Categories

Share

What does Shopify Competitor Price & Stock Monitor do?

Track competitor price changes, stockouts and restocks from public Shopify catalogs. Rolling mode remembers previous observations automatically: save a task, choose a schedule and receive relevant changes through your webhook. WooCommerce Store API catalogs are also supported, with the variation limits explained below.

For ecommerce agencies, merchandising teams and automation developers who need product observations with source URLs, timestamps and explicit before/after values. Export JSON or CSV, or connect change notifications to Make or n8n.

Price: $3 per 1,000 delivered product observations + $0.001 per run. Platform usage is included in this Actor's usage price. One product with nested variants counts as one observation. Successful unchanged products are billed too. Failed stores produce no product-result charges; the run fee still applies.

Supports public Shopify catalogs and compatible WooCommerce Store API catalogs. Apify provides API access, saved tasks, scheduling and run reports.

Why use this Shopify competitor monitor?

CapabilityShopifyWooCommerce Store API
Public product title, URL, description, imagesYes, where publishedYes, where published
Product prices and catalog stock statusYes, where publishedYes, where published
Variant prices, SKUs and availabilityYes, where publishedUsually unavailable from the parent catalog response
Automatic comparison between runsRolling modeRolling mode
Price/stock change webhooksComparable prices and known stock transitionsComparable product prices and known product stock transitions
One-off catalog snapshots and selected-dataset comparisonManual modeManual mode

Requests use compatible public catalog endpoints. No Shopify admin key, WooCommerce API key, proxy subscription or browser setup is required. Stores must expose these endpoints and allow the requests. For a WooCommerce installation in a subdirectory, use its WordPress installation root.

How to use Shopify price and stock monitoring

  1. Enter the store root URL, for example https://www.lttstore.com/. Product and collection URLs are not accepted.
  2. Choose Rolling price and stock monitoring and enter a stable Monitor ID, such as my-shopify-competitors.
  3. Set a small product limit for the first run. If you have independently confirmed the store's currency, enter its uppercase code; otherwise leave it blank.
  4. Run once to establish the baseline. Check the product dataset and REPORT for store compatibility and coverage. The baseline does not trigger price/stock alerts.
  5. Save this configuration as an Apify task. Schedule that task daily at your preferred time and time zone. Keep the same Monitor ID between runs. Apify scheduling guide
  6. Optionally add a public HTTPS webhook you control. Use Make or n8n to turn the received changes into email, Slack messages or another downstream action.
{
"storeUrls": ["https://www.lttstore.com/"],
"platform": "shopify",
"monitoringMode": "rolling",
"monitorId": "my-shopify-competitors",
"maxProducts": 20,
"maxProductsPerStore": 20,
"maxSeconds": 120
}

This example intentionally omits currency and the optional webhook. It still records raw prices and can detect confirmed stock changes. Add "shopifyCurrency": "USD" only if you have confirmed that the monitored catalog uses USD. Example storefront access may change over time.

Running this Actor does not create a schedule. Customers create and control their own schedules. There is no always-on process and the Actor does not send email directly.

Input

SettingDefaultMeaning
storeUrlsRequired1–50 public store root URLs; exact normalized duplicates are removed.
platformautoauto, shopify or woocommerce. Auto tries the other platform only when the first catalog endpoint is absent or unsupported.
monitoringModemanualmanual preserves existing snapshot behavior; rolling maintains comparison state automatically.
monitorIdEmptyRequired for rolling. 1–80 characters: letters, numbers, underscores or hyphens; first character must be a letter or number.
webhookUrlEmptyOptional public HTTPS JSON receiver in rolling mode. Stored as secret input.
previousDatasetIdEmptyManual mode only: one prior dataset from this Actor, up to 10,000 rows or 12 MB of comparison data.
shopifyCurrencyEmptyConfirmed uppercase currency code applying to every Shopify store in this run, such as USD.
maxProducts500Total delivered observations; 1–10,000.
maxProductsPerStore100Per-store cap; 1–5,000.
maxSeconds240Catalog processing budget; 10–480 seconds.

Use rolling mode without previousDatasetId. Keep the Apify run timeout above the catalog processing budget to allow state reads, exports, persistence and optional notifications. Store requests are sequential and rate limited. Customer spending limits can stop collection before the product caps are reached.

Output

Example excerpt generated from a controlled test product: a price rises from $10.50 to $12.50 and its Blue / M variant becomes unavailable. This is an example, not an observed merchant change. The actual changes array also includes affected aggregate and variant fields.

{
"title": "Example Blue Hat",
"url": "https://example.com/products/blue-hat",
"currency": "USD",
"priceMin": "12.5",
"inStock": false,
"changeType": "changed",
"changes": [
{
"field": "priceMin",
"before": "10.5",
"after": "12.5"
},
{
"field": "variants[2].inStock",
"before": true,
"after": false
}
]
}

Each dataset row represents one product successfully observed during the current run.

Prices are decimal strings, such as "19.95", to preserve precision. Missing data remains null or an empty collection. JSON retains nested variants and detailed changes.

Additional records in each run's key-value store:

  • PRODUCTS_CSV — flat product export; spreadsheet formula-like cells are escaped.
  • REPORT — delivered/changed totals, per-store coverage, request counts, stopping reasons and rolling-monitor results where applicable.
  • UNRESOLVED — incomplete or unsuccessful store scans and their reasons.
  • NOT_OBSERVED — prior products not observed this time, without claiming deletion or a stockout.
  • CHANGES — confirmed price/stock events detected in this rolling run, even without a webhook.
  • MONITOR_STATUS — rolling state and delivery results, also available as REPORT.monitor: eventsDetected, eventsDelivered, eventsPending, deliveryIssue, baselineGeneration and the persistent stateStoreId.

CHANGES and MONITOR_STATUS are produced in rolling mode. productsChanged in REPORT includes other catalog changes too, so it need not equal the number of price/stock events.

The first observation is baseline. Matching prior products become unchanged or changed. new_to_comparison means absent from the chosen comparison state, not necessarily newly launched by the merchant. Observation timestamps alone do not trigger a change.

You can download the dataset in various formats such as JSON, HTML, CSV, or Excel.

Data table

FieldsContents
key, platform, storeUrl, productIdStable identity and source store.
title, url, sku, brand, productTypeProduct details where published.
currency, currencySource, priceMin, priceMax, regularPriceMinMonetary values and their context.
inStock, variants, variantCount, variantsTruncatedCatalog availability and available variation details.
descriptionText, imagesCleaned description and up to 10 image URLs.
changeType, changes, changeCountComparison status and exact before/after values.
observedAt, previousObservedAt, sourceUrlCurrent/prior observation timestamps and source endpoint.

Pricing / Cost estimation

Delivered observationsRunsActor usage charge
201$0.061
1001$0.301
1,0001$3.001
100 per day for 30 days30$9.03

These are Actor usage charges in USD at $0.003 per delivered observation plus $0.001 per run. Unchanged observations are charged because they still require collection. Comparison and reports do not add product-result charges. Customer plan fees, external workflow services and applicable taxes are separate. These examples are customer spending, not developer profit.

Tips and advanced options

Baselines, failures and comparison scope

Use one Monitor ID per stable set of stores, platform and currency settings in the same Apify account. Tasks in the same account share state if they reuse the ID. Changes to store URLs, platform or currency require a new ID and a fresh baseline. Reusing an ID is how later runs find the previous observations; using a different ID starts over.

Rolling mode keeps the last successfully observed version of each product. A request failure, an unavailable store or a product missing from a partial scan does not change that product to out of stock. Missing products are reported separately, with no claim that they were deleted. When a product is seen again, it can be compared with its last good observation, which may be older than the immediately preceding run. Observed timestamps describe product fetches, not exact change times; an individual retained fact can come from an older observation.

Keep product limits and scheduling consistent. A small limit covers only part of a catalog; it is not a way to select specific product URLs. Inspect REPORT and NOT_OBSERVED to see coverage. Each monitor retains at most 10,000 products, 1,000 historical variants per product and 10,000 pending notification events, subject to a combined 16 MB state limit. A capacity failure preserves the existing state; resolve delivery failures or use a smaller scope with a new Monitor ID. Observations delivered before such a failure can still be billed.

Run each Monitor ID sequentially. Allow the preceding run to finish before starting another, including manual retries. The storage check reduces accidental overlap but is not a guarantee of atomic locking across simultaneous starts. An interrupted run may leave a lease that expires after 15 minutes.

Connect changes to Make or n8n

  1. Create a Make Custom webhook or an n8n Webhook endpoint that accepts JSON POST requests. Use a public HTTPS production endpoint you control.
  2. Paste that endpoint into the Actor's optional Change webhook URL field in rolling mode. Apify stores this field as a secret input.
  3. Establish the baseline, then run the same monitor again after a real source change, or use the example event below while building your receiver.
  4. Map each received change into your chosen email or Slack action. Configure credentials and recipients in your own workflow.
  5. Inspect REPORT after runs for notification results as well as catalog coverage. Deduplicate received events by eventId; do not assume every run generates a notification. Return a 2xx response when your receiver has accepted a batch.

The Actor posts { "schemaVersion": 1, "monitorId": "...", "events": [...] }. Each event contains product identity, URL, current/prior timestamps and changes with field, before, after and type. Change types are price_change, stockout and restock. One product may generate several changes, and large products are split into events of at most 50 changes.

Delivery is bounded to 10 requests and 30 seconds per run, with at most 50 events and 200 KB per request. Failed or timed-out delivery remains queued for the next run with the same eventId. Notifications can be duplicated when a response is lost; delivery is not exactly once. Redirects are not followed. A successful HTTP response confirms endpoint acceptance, not final email or Slack delivery.

If events are pending, keep the same webhook URL until they are delivered. Changing or removing the URL is rejected to preserve the queued events; restore the original URL to retry or use a new Monitor ID. With no webhook configured, events are available in CHANGES but are not queued for future webhook delivery.

The payload is generic JSON, not the format expected by a direct Slack incoming webhook. Make/n8n and notification services have their own account requirements and usage limits. The Actor does not provision or subscribe you to them.

Notifications concern confirmed price changes and known stock transitions. A first observation, an unchanged product, an unknown stock value or an unverified-currency price string is not a confirmed price/stock event. Other catalog differences remain visible in each row's changes array.

Example webhook event

This complete JSON payload was generated from the controlled example product above. It is test data, not a real competitor change. Use it to build your receiver; the eventId is for this example only.

{
"schemaVersion": 1,
"monitorId": "example-competitors",
"events": [
{
"type": "product_changed",
"monitorId": "example-competitors",
"productKey": "shopify|https://example.com|5",
"productId": "5",
"title": "Example Blue Hat",
"url": "https://example.com/products/blue-hat",
"storeUrl": "https://example.com",
"currency": "USD",
"observedAt": "2026-09-22T09:00:00+00:00",
"previousObservedAt": "2026-09-21T09:00:00+00:00",
"changes": [
{
"field": "inStock",
"before": true,
"after": false,
"type": "stockout"
},
{
"field": "priceMin",
"before": "10.5",
"after": "12.5",
"type": "price_change"
},
{
"field": "priceMax",
"before": "10.5",
"after": "12.5",
"type": "price_change"
},
{
"field": "variants[2].inStock",
"before": true,
"after": false,
"type": "stockout"
},
{
"field": "variants[2].price",
"before": "10.5",
"after": "12.5",
"type": "price_change"
}
],
"eventId": "d33e6cc018e108b96012b4232a426831b9a4af46dc61db82ed62389965378ba5"
}
]
}

Manual snapshots and comparison

Existing integrations remain in manual mode unless they explicitly select rolling mode. For a first snapshot, omit previousDatasetId. For comparison against a particular run, supply that run's accessible dataset ID:

{
"storeUrls": ["https://rootree.ca/"],
"platform": "woocommerce",
"monitoringMode": "manual",
"previousDatasetId": "YOUR_PREVIOUS_DATASET_ID",
"maxProducts": 100,
"maxProductsPerStore": 100,
"maxSeconds": 240
}

Replace the placeholder with one previous run's dataset from this Actor. A scheduled manual run with a fixed dataset always compares against that fixed dataset. Choose rolling mode for automatic baseline updates.

Currency, variants and availability

Shopify's public catalog does not reliably declare currency. Leave shopifyCurrency blank unless independently confirmed. Raw price strings remain in the output, but differences with unknown or changed currency receive an Observed field suffix and currency_unverified or currency_changed context. They do not generate numerical price alerts. Batch stores with different currencies separately.

WooCommerce declares currency and minor units, which the Actor uses to normalize prices. Its parent catalog generally does not provide individual variation prices, SKUs or stock, so those values remain unknown. Up to 250 variants are included per product; variantCount and variantsTruncated expose the limit.

Catalog stock status does not guarantee checkout availability. This Actor does not access secret inventory, customers or sales volumes, and does not calculate shipping, checkout taxes or geographic discounts.

FAQ, limitations and support

Private catalogs, headless storefronts, incompatible plugins, robots exclusions and access challenges may prevent collection. The Actor respects robots rules and stops on access restrictions; it does not use access circumvention or JavaScript rendering. Pagination, product caps, time limits, spending limits and response-size limits may produce partial scans. A catalog can change while it is being read, so even a completed scan is not an atomic snapshot.

Scheduling automates repeated invocation, but store changes and failed integrations may require attention. Check coverage and delivery reports periodically. No uninterrupted monitoring or notification delivery is guaranteed.

AI-agent callers can use the same structured inputs and outputs. A one-off purchase or x402 invocation does not itself establish a recurring monitor: recurring use needs the caller's persistent storage context and scheduling. This Actor does not claim x402 eligibility or guaranteed agent discovery.

Use the Issues tab to report a compatibility problem. Include the store root URL, run ID and report reason; do not post tokens or webhook URLs.