Marketplace Seller Watch — Third-Party Reseller Monitor avatar

Marketplace Seller Watch — Third-Party Reseller Monitor

Under maintenance

Pricing

from $20.00 / 1,000 seller-change alerts

Go to Apify Store
Marketplace Seller Watch — Third-Party Reseller Monitor

Marketplace Seller Watch — Third-Party Reseller Monitor

Under maintenance

Meta-scraper that tracks which third-party sellers offer a brand's products across European marketplaces (Kaufland.de, Kaufland.pl, Bol.com) and emits new_seller and seller_gone change events run over run — a deduped alert feed, not a full re-export.

Pricing

from $20.00 / 1,000 seller-change alerts

Rating

0.0

(0)

Developer

Studio Amba

Studio Amba

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

3 days ago

Last modified

Share

Marketplace Seller Watch

Track which third-party sellers offer a brand's products across European marketplaces, and get alerted the moment a new reseller appears or a known one disappears. One unified schema, deduplicated run over run, so every run returns only what changed.

Why use this actor?

Brand owners, distributors and channel managers all fight the same problem: unauthorized or unexpected resellers show up on marketplaces, undercut the agreed price, or a grey-market seller appears overnight. Checking each marketplace by hand is slow, and re-exporting every listing every day just to spot the difference is wasteful. This actor does the diffing for you. Point it at a brand (e.g. Philips), run it on a schedule, and each run only returns the sellers that are new since the last run, plus the ones that dropped out.

It is a meta-actor: under the hood it fans out to our own marketplace scrapers, collects the seller behind every matching listing, and diffs that set against a persistent, named key-value store that remembers what it has already seen across separate scheduled runs (not just within one run).

How to monitor marketplace sellers in Europe

  1. Enter the brand or product line you want to watch in brandQuery (for example Philips, or a specific model like Philips 5400 Series).
  2. Pick the marketplaces, or leave the field empty for the healthy defaults (Kaufland.de, Kaufland.pl, Bol.com).
  3. Run it once. The first run has nothing to compare against, so it seeds its memory and reports every current seller as a new_seller event — that run is your baseline. In a live seed run against Philips, this returned 17 sellers (12 distinct third-party merchants on Kaufland.pl such as NetworkTechnologies, Morelenet, SuperTechPL; plus sellers on Bol.com).
  4. Schedule it (see below). Every subsequent run returns only changes: a new_seller event when a reseller you hadn't seen starts offering the brand, and a seller_gone event when a previously-seen seller no longer appears in the tracked listings.
  5. Wire the output into an integration (Zapier, Make, a webhook, Slack) so a new reseller lands in front of your channel team the same day it appears.

What counts as a "seller"

Each marketplace listing carries the merchant selling it. On true marketplaces like Kaufland, that is an independent third-party merchant (NewHits, Xenudo, Glowcart, evomag, …), which is exactly the signal a brand wants. On Bol.com, the platform's own retail listings report the seller as bol, while genuine third-party "Verkoop door <merchant>" listings report the real merchant — so a shift on Bol.com from bol to a named reseller, or a new reseller appearing, is a meaningful event.

Scheduling

This actor is built to run on a schedule, not as a one-off. In the Apify Console:

  1. Open the actor, go to Schedules → Create new schedule.
  2. Daily (e.g. 0 6 * * *, 6am UTC) is a sensible cadence — marketplace assortments shift day to day, and a daily run keeps the delta small and readable. Weekly works if you only need coarse coverage.
  3. Keep the same brandQuery on every scheduled run. The seen-set is namespaced per brand, so tracking Philips and Sony in two schedules keeps their histories separate.
  4. Do not turn on resetState on a scheduled run — that flag wipes the seen-set for the brand and would make every run look like a first run, defeating the point.

Input

FieldTypeRequiredDescription
brandQueryStringNoBrand or product line to track. Empty defaults to Philips.
marketplacesArrayNoWhich marketplaces to watch: kaufland-de, kaufland-pl, bol, allegro. Empty = the healthy defaults (kaufland-de, kaufland-pl, bol).
productNameStringNoNarrow tracking to one product. Only listings similar enough to this name are counted (see matchThreshold). Empty = every listing the brand query returns.
matchThresholdNumberNoMinimum name-similarity (0–1) when productName is set (default 0.35).
maxProductsPerMarketplaceIntegerNoListings to pull per marketplace per run (default 20). More listings find more sellers but cost more.
emitSellerGoneBooleanNoEmit seller_gone when a known seller drops out of the tracked listings (default true).
timeoutPerSourceSecsIntegerNoMax wait per marketplace scraper before it's marked failed and skipped (default 240).
proxyConfigurationObjectNoPassed through to marketplaces that need one (Bol.com; Allegro when opted in). Kaufland drives Bright Data internally and ignores this.
resetStateBooleanNoTesting only — wipes the brand's seen-set before the run. Never use on a real schedule.

Output

One row per change event, plus a single status row on a legitimate zero-delta run (sources healthy, nothing changed).

FieldTypeExample
eventTypeString"new_seller"
marketplaceString"kaufland-pl"
sellerNameString"NetworkTechnologies"
productNameString"Philips 800 series EP0824/00"
eanString"8720389016479"
priceNumber1216.35
currencyString"PLN"
countryString"PL"
detectedAtString"2026-07-21T13:18:02.801Z"
sellerUrlString"https://www.kaufland.de/product/448814482/"
matchTypeString"ean"
matchScoreNumbernull

Example rows

{ "eventType": "new_seller", "marketplace": "kaufland-pl", "sellerName": "BRaUN_Elektro",
"productName": "Philips 5000 series Airfryer HD9255/30", "ean": "8720389022166",
"price": 389.64, "currency": "PLN", "country": "PL",
"detectedAt": "2026-07-21T13:31:00.000Z", "matchType": "ean", "matchScore": null }
{ "eventType": "seller_gone", "marketplace": "kaufland-pl", "sellerName": "Agmi",
"productName": "", "ean": "", "price": null, "currency": "PLN", "country": "PL",
"detectedAt": "2026-07-21T13:31:00.000Z", "matchType": null, "matchScore": null }

Marketplaces covered

MarketplaceCountryCurrencySeller dataNotes
Kaufland.deDEEURYes — distinct third-party merchants + EANBest source: a true open marketplace.
Kaufland.plPLEUR/PLNYes — distinct third-party merchants + EANSame engine, Polish market.
Bol.comNL/BEEURYes — bol for first-party, named merchant for third-party + EANNeeds a residential proxy (default).
Allegro.plPLPLNOpt-in onlyAllegro exposes the seller only on product detail pages; the listing scraper returns no seller today, so this marketplace is not in the defaults.

How pricing works

Pay-per-event: a small charge when the actor starts, then a charge per change-event row (new_seller / seller_gone). A quiet run that finds no changes emits a single status row, so you are never billed for a full re-export you didn't need — you pay for signal, not noise.

Limitations (read these)

  1. seller_gone is judged against the tracked window. A run pulls up to maxProductsPerMarketplace listings. If a seller drops out of that top-N window (because live marketplace ranking shifted, not because they actually left), it is reported seller_gone. Raise maxProductsPerMarketplace for a wider, steadier window if you see churn. Read seller_gone as "no longer appears in the tracked listings," which is the honest claim.
  2. No seller-profile URL. None of the underlying scrapers expose a seller's marketplace profile URL, so sellerUrl points to the product listing where the seller was found — that is where you verify the seller by hand.
  3. A failed marketplace is skipped, not faked. If a marketplace scraper times out or errors (Kaufland runs Bright Data, which can be slow), that marketplace contributes nothing to that run rather than producing false seller_gone events. Only a run where every marketplace fails is treated as an error.
  4. First run is the baseline. The very first run for a brand/marketplace reports every current seller as new_seller. That is intended — it seeds the memory. The value is in every run after it.
  5. eMAG (RO) and Otto (DE) are not included. Their scrapers expose no per-listing seller field, so they cannot support a seller-watch product. Kaufland and Bol do.

How to scrape Marketplace Seller Watch data

  1. Go to this actor's page on the Apify Store.
  2. Click Try for free to open it in Apify Console.
  3. Configure your search query or URL, set the maximum number of results, and adjust proxy settings if needed.
  4. Click Start and wait for the run to finish.
  5. Download your data in JSON, CSV, Excel, or connect it to your workflow via API.

You can also schedule regular runs, set up webhooks for real-time notifications, or integrate the results directly into your application using the Apify API.