DEV Community: KazKN

I Built the Wrong Scraper First. The Data Looked Clean and Was Still Useless.

KazKN — Fri, 12 Jun 2026 01:27:35 +0000

I built the wrong scraper first.

It worked.

That was the problem.

The scraper extracted product titles, prices, URLs, images, and brands. The dataset was clean. The rows looked normal. Nothing crashed.

But the output was still not useful enough.

The mistake was simple: I treated a resale marketplace like a product catalog.

It is not.

A marketplace has state.

The clean dataset trap

This looked fine:

{
  "title": "Leather bag",
  "price": 1200,
  "brand": "Example",
  "url": "https://example.com/item/123"
}

But the real questions were missing:

Is it live or sold?
Did it disappear since the last run?
Which country was searched?
Where is the seller?
What condition is the item in?
Has the price changed?
Is this listing unusually similar to another listing?

None of those questions are visible in a basic product-card scrape.

What I changed

I stopped designing the output around the page.

I started designing it around decisions.

The row became more explicit:

{
  "recordType": "listing",
  "displayStatus": "Available",
  "isSold": false,
  "country": "FR",
  "sellerCountry": "IT",
  "condition": "Very good condition",
  "price": 1200,
  "priceHistory": [],
  "requiresManualReview": false
}

Less pretty.

Much more useful.

The lesson

Selectors are not the product.

The state model is the product.

If the scraper cannot preserve state, it will make the dataset feel more certain than it really is.

That is dangerous because clean JSON is easy to trust.

The checklist I use now

Before I trust a marketplace scraper, I check whether it handles:

live items;
sold items;
disappearing items;
seller country;
page country;
item condition;
price history;
duplicate or similar listings;
manual-review signals.

If it does not, I treat the dataset as a starting point, not a decision layer.

The uncomfortable part

The broken version was easier to explain.

"It scrapes product data" is simple.

"It models marketplace state" takes longer.

But the second one is the version I would actually use.

Have you ever shipped a scraper that was technically correct but operationally useless?

Your Scraper Returns 200 OK and Still Lies: 7 Marketplace Checks I Use

KazKN — Fri, 12 Jun 2026 01:25:30 +0000

The easiest scraper bug to miss is not a crash.

It is a clean result that is wrong.

The request returns 200 OK.

The selector works.

The dataset has rows.

The dashboard looks alive.

And still, the output can lie.

That happens often on marketplaces because a marketplace is not just a list of product cards. It is a changing state machine.

Here is the checklist I now use before trusting marketplace scraping data.

1. Separate live records from sold records

Active listings and sold listings answer different questions.

Active listings show supply.

Sold listings show demand.

If both go into one dataset without a clear recordType, later analysis gets unreliable.

{
  "recordType": "listing",
  "isSold": false
}

{
  "recordType": "sold_item",
  "isSold": true
}

2. Treat disappearance as an event

If a listing disappears, do not silently delete it from your mental model.

Emit a tracking record.

{
  "recordType": "tracking_event",
  "event": "previously_seen_listing_missing",
  "listingId": "123"
}

You may not know whether it sold, expired, or was removed.

But you do know something changed.

3. Store page country and seller country separately

This one sounds minor until it breaks your analysis.

country can mean the market page you searched.

sellerCountry can mean the seller location exposed by the listing.

Those are not the same thing.

{
  "country": "DE",
  "sellerCountry": "FR"
}

If you merge them, your cross-market analysis becomes noise.

4. Add precision filters after broad search

Marketplace search is optimized for discovery, not clean datasets.

A broad query often returns nearby products.

So I like a second layer:

{
  "searchTerms": ["classic flap"],
  "requiredKeywords": ["classic", "flap"]
}

This does not make search perfect.

It makes the dataset easier to inspect.

5. Make condition a first-class field

Price without condition is incomplete.

For resale marketplaces, condition changes the meaning of every price.

{
  "price": 1000,
  "condition": "Very good condition",
  "conditionSource": "marketplace"
}

If condition is hidden in a description string, you will forget to use it.

6. Track price history, not only price

One scrape tells you what existed.

Repeated scrapes tell you what changed.

{
  "priceHistory": [
    { "price": 1400, "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1200, "observedAt": "2026-06-08T12:00:00.000Z" }
  ]
}

For monitoring, the delta is usually more useful than the snapshot.

7. Use risk signals as review queues

Do not make accusations from scraper output.

If listings look suspiciously similar, surface them as review candidates.

{
  "recordType": "risk_signal",
  "signalType": "similar_listing_cluster",
  "confidence": "review_required"
}

That gives a human a useful queue without pretending the scraper has certainty.

The real test

I do not trust a marketplace scraper because it extracts rows.

I trust it when it preserves enough context to answer:

what exists now?
what sold?
what disappeared?
where was it found?
where is the seller?
did the price change?
what needs manual review?

That is the difference between scraping a page and modeling a marketplace.

What check would you add before trusting marketplace data in production?

AI Agents Make Scraping Look Easy. Marketplace State Is Where They Lie.

KazKN — Fri, 12 Jun 2026 01:25:28 +0000

AI agents make scraping look easy.

Give the agent a page.

Ask for JSON.

Get back a clean object.

{
  "title": "Leather bag",
  "price": 1200,
  "url": "https://example.com/item/123"
}

That feels useful.

It is often not enough.

The hard part of marketplace scraping is not always extracting the card.

The hard part is knowing whether the card still means what you think it means.

200 OK can still be wrong

A scraper can return a valid HTTP response, parse the page, extract the title and price, and still give you bad operational data.

The page did load.

The selector did work.

The JSON did validate.

But the marketplace state may be wrong.

Examples:

The item is visible in search but already sold.
The item disappeared, but you do not know whether it sold or was deleted.
The same listing appears across several market locales.
The seller country matters more than the page country.
The search term matches a nearby model, not the model you wanted.
The current price looks low, but the item condition explains why.
The product card hides details that only exist on the item page.

This is where AI extraction can create false confidence.

It makes the data look cleaner than the marketplace really is.

The mistake: treating marketplaces like catalogs

A catalog has products.

A marketplace has state.

For a catalog scrape, this might be enough:

{
  "title": "Product name",
  "price": 49,
  "availability": "In stock"
}

For a resale marketplace, I want a different shape:

{
  "recordType": "listing",
  "listingId": "123",
  "displayStatus": "Available",
  "isSold": false,
  "country": "FR",
  "sellerCountry": "IT",
  "condition": "Very good condition",
  "price": 1200,
  "priceHistory": [
    { "price": 1400, "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1200, "observedAt": "2026-06-08T12:00:00.000Z" }
  ],
  "requiresManualReview": false
}

That object is less pretty.

It is also more honest.

The seven checks I use now

Before trusting marketplace data, I want seven checks.

1. Live and sold records should not be mixed

Active listings tell you supply.

Sold listings tell you demand.

If both are pushed into the same flat dataset without a clear recordType, analysis becomes messy quickly.

2. Disappearance is a signal

If an item was present yesterday and missing today, the scraper should not silently forget it.

It should emit a tracking record.

Something changed.

That change may be more useful than another active listing.

3. Page country is not seller country

On international marketplaces, the locale you searched and the seller location are different concepts.

If you only store one country field, you will eventually confuse yourself.

I prefer:

{
  "country": "FR",
  "sellerCountry": "IT"
}

One tells me where I searched.

The other tells me where the seller appears to be.

4. Search terms need precision filters

Marketplace search is fuzzy.

That is useful for browsing.

It is dangerous for automation.

If the query is classic flap, I want the option to require those words in the result, not merely trust the search engine.

5. Condition changes the meaning of price

A low price without condition is not a deal.

It is just incomplete data.

I want condition and conditionSource visible in the output.

6. Price history matters more than current price

The current price is a snapshot.

The price movement is the signal.

If a scraper runs repeatedly, it should preserve enough state to answer:

did the price drop?
did it rise?
how long has it stayed at this level?
did it disappear after the drop?

7. Risk signals should be review queues, not accusations

If two listings look unusually similar, that is worth surfacing.

But a scraper should not declare fraud.

The safer output is:

{
  "recordType": "risk_signal",
  "signalType": "similar_listing_cluster",
  "confidence": "review_required"
}

That gives the human a queue.

It does not pretend the scraper knows more than it does.

Where AI helps

AI can still help a lot.

It can normalize messy titles.

It can classify categories.

It can summarize product descriptions.

It can help detect weird edge cases in extracted records.

But I do not want AI to hide uncertainty.

For marketplace scraping, the best output is not the cleanest JSON.

The best output is the JSON that preserves enough context to make a decision.

My rule now

If a scraper cannot explain state, I do not trust its clean output.

I want to know:

what exists now;
what disappeared;
what sold;
where it was found;
where the seller appears to be;
how the price changed;
what needs manual review.

Selectors are only the first layer.

The real product is the state model.

What is the most dangerous false-positive your scraper has returned?

Vestiaire Collective Scraper: 7 Checks I Built After Reading 11,263 Reviews

KazKN — Wed, 10 Jun 2026 20:14:32 +0000

The first version of my Vestiaire Collective scraper would have been boring.

Search page. Product title. Price. URL.

That is how most marketplace scrapers start.

Then I read 11,263 public App Store and Google Play reviews, plus a Trustpilot sample, and the product brief changed.

People were not only talking about clothes, bags, or luxury resale. They were talking about uncertainty:

"seller"
"sold"
"fake"
"refund"
"fees"
"condition"
"customer service"
"money back"
"doesn't work"

That language points to a different kind of scraper.

Not just a product-card scraper.

A marketplace intelligence scraper.

So I built the Vestiaire Collective Smart Scraper on Apify around the checks that help reduce uncertainty: sold items, seller countries, price tracking, item condition, product details, and duplicate or suspicious listing signals.

Disclosure: this article contains affiliate links to my Apify Actor.

The short version

If you are scraping a resale marketplace, title and price are not enough.

Here is the checklist I ended up building around:

Track live listings and sold items separately.
Separate market country from seller country.
Extract condition and condition source.
Add precision filters for exact models.
Enrich product details beyond the search card.
Track price changes, not only current price.
Surface duplicate/risk signals without accusing anyone.

That checklist is more useful than another "how to scrape product cards" tutorial.

Reviews are product research

A normal ecommerce scrape might output this:

{
  "title": "Designer bag",
  "price": 1200,
  "url": "https://..."
}

That works for a simple catalog.

Vestiaire Collective is not a simple catalog.

It is a resale marketplace where the useful questions are more specific:

Is the item still available or already sold?
Where is the seller located?
Is the condition clearly exposed?
Is the product page richer than the search result?
Did the price change since the last run?
Does the same item appear in several market pages?
Are similar listings clustered in a way that deserves manual review?

The reviews made this obvious.

When users talk about refund, fees, commission, and money back, they are asking for better price context.

When they talk about fake, authentication, photos, description, and condition, they are asking for better product and risk context.

When they talk about seller, buyer, sold, and selling, they are asking for marketplace intelligence.

The 7 checks

1. Live and sold items are different datasets

Active listings show supply.

Sold listings show demand.

If you only scrape active listings, you miss the part of the market that actually moved.

That is why the Actor supports includeSoldItems:

{
  "searchTerms": ["chanel classic flap"],
  "countries": ["FR", "IT", "DE", "GB"],
  "includeSoldItems": true,
  "maxListings": 100,
  "maxDatasetRecords": 150,
  "maxPagesPerCountry": 2
}

For resale research, sold signals are often more valuable than active prices.

2. Market country is not seller country

This caused confusion during testing, so it is worth spelling out.

country is the Vestiaire market page searched.

sellerCountry is where the seller or item appears to be located in the public listing data.

If you want to compare market pages, use countries:

{
  "countries": ["FR", "IT", "DE", "GB"]
}

If you only want sellers from France, search broadly and filter narrowly:

{
  "countries": ["ALL"],
  "sellerCountries": ["FR"]
}

That distinction matters because a user might discover the same relevant item from several market locales.

The seller location is often the real constraint.

3. Condition has to be visible in the output

Review language around condition, description, photos, and not as described came up too often to ignore.

The scraper should not hide condition in an unstructured blob.

It should expose it as a field:

{
  "condition": "Very good condition",
  "conditionSource": "vestiaire"
}

And it should let users filter before collecting too much noise:

{
  "itemConditions": ["3", "4"]
}

In this Actor:

3 means very good condition.
4 means good condition.

4. Broad search terms create messy datasets

A query like chanel classic flap can return nearby but irrelevant results.

That is not a scraper bug. It is how marketplace search behaves.

So I added a precision filter:

{
  "searchTerms": ["chanel classic flap"],
  "requiredKeywords": ["classic flap"]
}

This lets the user encode the model they actually care about instead of cleaning the dataset manually afterward.

5. Search cards are not enough

Search results are useful for discovery.

Product detail pages are useful for decisions.

That is why includeDetails exists.

It can add richer public product information when available, such as title, brand, category, materials, dimensions, item condition, images, and product page fields.

Use it when quality matters more than speed:

{
  "includeDetails": true
}

Leave it off for quick market scans.

6. Price history beats one-off price extraction

A one-time price is a snapshot.

A repeated scrape becomes monitoring.

The Actor can keep tracking state between runs and build public price history for known listings:

{
  "listingId": "67486244",
  "priceHistory": [
    { "price": 1200, "currency": "EUR", "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1000, "currency": "EUR", "observedAt": "2026-06-08T12:00:00.000Z" }
  ],
  "displayStatus": "Available"
}

That opens up more useful workflows:

price-drop monitoring;
deal alerts;
sell-through research;
recurring watchlists;
cross-country price comparison.

7. Risk signals should stay conservative

Reviews use strong words: fake, scam, avoid, fraud, stolen.

A scraper should not turn those emotions into accusations.

It should surface review queues.

That is why duplicate and suspicious listing outputs are framed as signals:

{
  "recordType": "risk_signal",
  "signalType": "similar_listing_cluster",
  "confidence": "review_required",
  "listingIds": ["..."],
  "sharedFields": ["brand", "title", "image", "priceBand"]
}

This is not proof.

It is a shortlist for manual inspection.

That is the responsible level for a luxury resale workflow.

A practical run I would use

Here is a deal-finding run:

{
  "searchTerms": ["chanel classic flap"],
  "countries": ["ALL"],
  "sellerCountries": ["ALL"],
  "itemConditions": ["3", "4"],
  "requiredKeywords": ["classic flap"],
  "maxListings": 50,
  "maxDatasetRecords": 80,
  "maxPagesPerCountry": 2,
  "includeDetails": true,
  "includeSellerInfo": true,
  "includeDuplicateSignals": true,
  "includeSoldItems": false
}

Why countries: ["ALL"]?

Because you do not always know which market locale will expose the relevant listing.

Why sellerCountries: ["ALL"]?

Because for deal discovery, I usually want the market first, then I narrow by seller country after looking at the data.

If I only want French sellers, I change one line:

{
  "sellerCountries": ["FR"]
}

That turns a broad market scan into a seller-location scan.

The output should be readable

The useful row is not only the product.

It is the product plus the context around it:

{
  "recordType": "listing",
  "displayStatus": "Available",
  "isSold": false,
  "listingId": "67486244",
  "brand": "Chanel",
  "title": "Classic flap bag",
  "price": 1000,
  "currency": "EUR",
  "country": "FR",
  "sellerCountry": "FR",
  "condition": "Very good condition",
  "conditionSource": "vestiaire",
  "url": "https://fr.vestiairecollective.com/..."
}

That is the difference between scraping and workflow design.

When I would use this Actor

This is the checklist I would use to decide whether the Actor fits a job:

You want to compare active listings and sold signals.
You need seller-country filtering.
You want to monitor price changes over time.
You care about item condition.
You want product details beyond search cards.
You want duplicate or suspicious listing review queues.
You want JSON, CSV, Excel, or API export from Apify.
You want scheduled runs without maintaining your own scraper server.

The Vestiaire Collective Smart Scraper searches all 70 supported Vestiaire market countries by default when countries is empty or set to ALL, but you can restrict countries when you need smaller runs.

The goal is not to force one workflow.

The goal is to let users define their own risk model.

What it does not claim

This part matters.

The Actor does not prove that an item is authentic.

It does not accuse sellers.

It does not bypass private areas.

It works with public Vestiaire Collective data and turns public marketplace signals into structured rows for research, monitoring, and manual review.

A scraper should not invent certainty.

It should make uncertainty easier to inspect.

My takeaway

Reading the reviews changed what I built.

The useful product was not:

"Give me title, price, URL."

It was:

"Help me decide what deserves attention."

That is why the Actor is built around sold items, seller intelligence, price tracking, condition filters, product details, and duplicate signals.

If you were building resale marketplace intelligence, what would you track next?

Seller tenure, fee-adjusted net price, image similarity, shipping country, sold-date reliability, or something else?

How to Scrape Vestiaire Collective for Sold Items, Prices, and Seller Intelligence

KazKN — Tue, 09 Jun 2026 02:44:14 +0000

Vestiaire Collective is not a normal ecommerce website.

If you only scrape product titles and prices, you miss most of the value.

For luxury resale, the useful questions are different:

Which Chanel Classic Flap listings are priced below the market?
Which seller countries return the best supply for a specific model?
Which items have already sold?
Which listings disappeared after being tracked for several runs?
Which sellers keep posting very similar items?
Which markets expose the same listing several times?

That is why I built a scraper around resale workflows, not just around product pages.

You can run the ready-made Vestiaire Collective Smart Scraper on Apify if you want the hosted version, or use the structure below to understand what a serious Vestiaire Collective data workflow should collect.

Disclosure: this article contains affiliate links to my Apify Actor.

🧭 Why Vestiaire Collective scraping is different from normal ecommerce scraping

Most ecommerce scraping tutorials follow the same pattern:

Fetch a category page.
Extract product cards.
Open product pages.
Save title, price, image, brand, and URL.

That works for a standard retail catalog.

It is incomplete for Vestiaire Collective.

Vestiaire is a resale marketplace. The same brand and model can appear in many conditions, many seller countries, many currencies, and many market locales. A single search like chanel classic flap can return active listings, near-duplicates, irrelevant flap bags, different conditions, different seller locations, and sometimes the same item across several country pages.

So the useful dataset is not only:

{
  "title": "Chanel bag",
  "price": 4200,
  "url": "https://..."
}

The useful dataset looks more like:

{
  "recordType": "listing",
  "listingId": "67486244",
  "title": "Sac a main en cuir Classic CC Shopping",
  "brand": "Chanel",
  "price": 1000,
  "currency": "EUR",
  "country": "FR",
  "sellerCountry": "DE",
  "condition": "Bon etat",
  "isSold": false,
  "displayStatus": "active",
  "likesCount": 22,
  "url": "https://fr.vestiairecollective.com/..."
}

The difference is important. The second record can support sourcing, resale analysis, seller benchmarking, and price tracking. The first one is just a product card.

🧩 What data matters on Vestiaire Collective

For a useful Vestiaire Collective scraper, I would prioritize these fields:

Field	Why it matters
`listingId`	Deduplicate the same item across multiple market pages
`title` and `model`	Filter precise models like Classic Flap, Jackie, Kelly, or Saddle
`price` and `currency`	Compare resale prices across markets
`country`	The market locale searched, such as FR, IT, DE, GB, or US
`sellerCountry`	The seller or item location returned by Vestiaire
`condition`	Critical for underpriced deal detection
`isSold` and `displayStatus`	Separate live inventory from sold or likely sold records
`url`	Open the original listing for manual review
`priceHistory`	Track price drops over repeated runs
`seller summary`	Benchmark sellers seen in the collected data
`duplicate signals`	Flag similar public records for manual review

Two fields are often confused: market country and seller country.

country is the Vestiaire market searched. For example, you can search the French, German, or UK marketplace view.

sellerCountry is where the seller or item appears to be located according to the public data returned by Vestiaire.

For most sourcing use cases, seller country is usually more important than market country. If you want French sellers, use sellerCountries: ["FR"]. If you want to compare how the same query behaves across local market pages, use countries.

⚙️ Quick start with the ready-made Actor

The fastest way to collect this data is to run the Vestiaire Collective Smart Scraper.

It supports:

Search terms.
Public Vestiaire start URLs.
All 70 supported Vestiaire market countries.
Optional seller country filters.
Optional item condition filters.
Product detail enrichment.
Sold item collection.
Price history across repeated runs.
Likely sold tracking when listings disappear over time.
Seller summary rows.
Duplicate and suspicious seller signal rows.

The key design choice is that countries are not hardcoded to a few large markets.

If the user leaves countries empty or selects ALL, the Actor can search every supported Vestiaire market. If the user only wants France, Italy, Germany, the UK, or the US, they can restrict the run.

That matters because you do not always know the user's intent in advance.

A reseller might want only sellers in France. A market researcher might want all public market views. A pricing analyst might want to compare the same model across Europe and the US. The input should not block any of these workflows.

🧪 Example input for a deal-finding workflow

Here is a realistic workflow: find potentially underpriced Chanel Classic Flap listings from French, Italian, German, and UK markets, but only keep items in very good or good condition.

{
  "searchTerms": ["chanel classic flap"],
  "countries": ["FR", "IT", "DE", "GB"],
  "sellerCountries": ["ALL"],
  "itemConditions": ["3", "4"],
  "requiredKeywords": ["classic flap"],
  "maxListings": 50,
  "maxDatasetRecords": 80,
  "maxPagesPerCountry": 2,
  "includeDetails": true,
  "includeSellerInfo": true,
  "includeDuplicateSignals": false,
  "includeSoldItems": false
}

This input does several useful things.

It uses a broad search term, then tightens the result with requiredKeywords. That helps avoid collecting every Chanel flap bag when you only want Classic Flap candidates.

It searches several market locales, but it does not restrict seller country. That is useful when the goal is deal discovery. If your business only buys from specific countries, you can replace sellerCountries: ["ALL"] with something like:

{
  "sellerCountries": ["FR", "IT"]
}

The maxListings value controls the number of listing-like records. The maxDatasetRecords value controls total dataset rows, including details and seller summaries. If you enable enrichments, always give maxDatasetRecords more room than maxListings.

📦 Example output fields

A clean output should not force the user to decode raw website internals.

For each listing, I want the dataset to be readable directly inside Apify, CSV, Excel, or an API response.

Example listing row:

{
  "recordType": "listing",
  "displayStatus": "active",
  "isSold": false,
  "listingId": "67486244",
  "title": "Sac a main en cuir Classic CC Shopping",
  "brand": "Chanel",
  "price": 1000,
  "currency": "EUR",
  "priceText": "1000 EUR",
  "country": "FR",
  "sellerCountry": "DE",
  "condition": "Bon etat",
  "conditionSource": "vestiaire",
  "itemSummary": "Chanel - Sac a main en cuir Classic CC Shopping - 1000 EUR - DE"
}

Example tracking row after repeated runs:

{
  "recordType": "price_history",
  "listingId": "67486244",
  "displayStatus": "active",
  "priceHistory": [
    { "price": 1200, "currency": "EUR", "observedAt": "2026-06-01T12:00:00.000Z" },
    { "price": 1000, "currency": "EUR", "observedAt": "2026-06-08T12:00:00.000Z" }
  ],
  "priceDrop": 200
}

Example seller summary:

{
  "recordType": "seller_summary",
  "sellerCountry": "FR",
  "uniqueListings": 20,
  "averagePrice": 1850,
  "minPrice": 650,
  "maxPrice": 4200
}

This is the part most simple scrapers miss. Once you have seller summaries and tracking records, the dataset becomes a market intelligence workflow, not just a list of products.

💰 Cost model and pricing logic

For scraping tools, pricing has to match the value of the output.

If a competitor charges around 20 to 30 dollars per 1,000 results, a new Actor should not be randomly priced at 50 or 70 dollars per 1,000. It needs to be close enough to the market while still leaving margin.

For the current Actor pricing, the main paid event is the listing result. Search pages and enrichments are priced separately so users only pay more when they ask for deeper data.

Approximate effective pricing:

Workflow	BRONZE	SILVER	GOLD+
Listing-only results	About $20.08 per 1,000	About $18.06 per 1,000	About $16.05 per 1,000
Listing + product details	About $26.08 per 1,000	About $23.06 per 1,000	About $20.05 per 1,000
Sold item results	About $25.08 per 1,000	About $22.06 per 1,000	About $20.05 per 1,000

This makes free accounts useful for testing, but paid accounts quickly become more efficient for serious usage.

If you want to run it yourself, the live Actor is here: Vestiaire Collective Scraper on Apify.

🛠️ Building your own scraper vs using an Actor

You can build your own Vestiaire Collective scraper.

The basic architecture is straightforward:

Generate search URLs or API requests from query terms.
Loop through market countries.
Parse listing cards or public JSON data.
Normalize fields.
Deduplicate by listing ID.
Optionally fetch product detail pages.
Store state between runs for price history.
Export the dataset.

The hard part is not the first 50 lines of code.

The hard part is making the workflow reliable enough for actual users.

You need input validation, country handling, seller country filters, title precision filters, item condition filters, result caps, charge limits, retries, deduplication, clean output schemas, and a way to avoid marking old listings as sold just because one run failed.

For a personal script, you can keep it simple.

For a public data product, you need guardrails.

That is the main reason I packaged this as an Apify Actor. Users can run it from the UI, schedule it, export results, call it through the API, and reuse the same input without maintaining infrastructure.

🔍 Use cases this unlocks

Here are practical workflows this type of scraper can support.

Find underpriced luxury items:

{
  "searchTerms": ["chanel classic flap"],
  "itemConditions": ["3", "4"],
  "includeDetails": true
}

Track sold items for resale price research:

{
  "searchTerms": ["hermes kelly 28"],
  "includeSoldItems": true,
  "maxListings": 100
}

Monitor price drops over time:

{
  "searchTerms": ["dior saddle bag"],
  "trackingStoreName": "dior-saddle-weekly-tracking",
  "includeDetails": true
}

Benchmark sellers by country:

{
  "searchTerms": ["gucci jackie bag"],
  "sellerCountries": ["FR", "IT", "ES"],
  "includeSellerInfo": true
}

Find duplicate or suspicious public listing patterns:

{
  "searchTerms": ["louis vuitton neverfull"],
  "includeDuplicateSignals": true,
  "maxListings": 200,
  "maxDatasetRecords": 260
}

Duplicate signals are not proof of fraud. They are review signals. The goal is to surface listings or sellers that deserve a closer look, not to make a final authenticity decision.

You can test these workflows with the Vestiaire Collective Sold Items and Price Tracker Actor.

🧯 Practical scraping caveats

There are a few things to be careful with.

First, country selection and seller country selection are not the same thing.

If you search countries: ["FR"], you are searching the French market view. You may still see sellers from Germany, Italy, Spain, or elsewhere. If you want only French sellers, use sellerCountries: ["FR"].

Second, sold item tracking is not always a single perfect website flag.

Some records come from public sold search filters. Some records come from explicit sold pages. Some records become likely_sold only after they disappear across repeated tracking runs. A good scraper should show the source of the status instead of pretending every sold signal is equally certain.

Third, condition data can be incomplete.

If Vestiaire does not return a condition for a result, the scraper should not invent certainty. In my Actor, condition fields expose whether the value came from Vestiaire or from a selected filter fallback.

Fourth, duplicate detection must stay conservative.

Similar titles, images, brands, categories, and price bands can signal a duplicate cluster. They do not automatically prove counterfeit activity. Treat these records as manual review leads.

Finally, respect public data boundaries.

Do not use scraping to collect private account information, bypass access controls, or overload a website. Keep requests reasonable, cache when possible, and design your workflow around public data.

❓ FAQ

Q: Can I scrape sold items from Vestiaire Collective?

A: Yes, you can collect public sold-search results and public sold-item pages when available. For recurring tracking, you can also mark listings as likely_sold only after they are missing for a configured number of runs.

Q: What is the difference between market country and seller country?

A: Market country is the Vestiaire locale searched, such as FR, IT, DE, GB, or US. Seller country is the seller or item location returned in the public listing data. For sourcing, seller country is often the more useful filter.

Q: Do I need product detail enrichment?

A: Not always. Listing-only runs are cheaper and faster. Enable product details when you need richer product metadata, product page fields, or more confidence before manual review.

Q: Can I use this without writing code?

A: Yes. Apify Actors can run from the browser UI with JSON input. Developers can also call the same Actor through the Apify API and export results as JSON, CSV, Excel, or via dataset endpoints.

✅ Final thoughts

The main mistake with Vestiaire Collective scraping is treating it like a static product catalog.

The value is not only in scraping listings.

The value is in connecting listings with sold signals, seller location, condition, duplicate detection, and price history over time.

That is how you turn public marketplace pages into something useful for resale research, sourcing, competitive monitoring, and seller intelligence.

If you want the hosted version, start with the Vestiaire Collective Smart Scraper on Apify, run a small query first, inspect the output, then scale the run once the fields match your workflow.

Best Vinted Scraper in 2026: An Honest Developer Comparison

KazKN — Thu, 04 Jun 2026 21:19:51 +0000

I do not think "best Vinted scraper" is a useful question by itself.

The useful question is:

Best for which workflow?

A one-time CSV export, a seller watchlist, a price-drop monitor, and a sell-through tracker are different products.

This is the comparison I wish I had written before building Vinted Smart Scraper.

Disclosure: I built this Actor. Some Apify links may use my referral code.

🧨 What most comparisons get wrong

A lot of scraper comparisons only test this:

Can it return rows today?

That is not enough.

For a reseller workflow, I care about:

Question	Why it matters
Can it run on a schedule?	Manual scraping does not compound
Can it keep state?	Price history and sell-through need memory
Does it fail cleanly?	Bad rows can poison alerts
Can I cap cost?	Scheduled jobs can quietly become expensive
Does it handle countries?	Vinted is not one uniform marketplace
Does the output help decisions?	Rows are not the same as signals

The best tool is not the one with the biggest export button.

It is the one that lets a user wake up, check signals, and decide what to buy, ignore, or monitor next.

🧭 The comparison matrix

Approach	Good at	Weak at
Manual Vinted search	Quick checks	No history, no automation
One-time scraper	CSV exports	No recurring signal
Browser-only scraper	Complex pages	Slow, session-heavy
Catalog/API-style scraper	Fast listing snapshots	Needs fallback strategy
Scheduled monitor	Recurring decisions	Requires state and cost guardrails

Here is the stricter version:

Approach	Setup	26 markets	Scheduling	State	Failure behavior	Best user
Manual Vinted search	✅ Easy	✅ Native	❌ None	❌ None	Human judgment	Casual buyer
One-time scraper	✅ Easy	Maybe	❌ Weak	❌ None	Often hidden	CSV user
Browser-only scraper	Medium	Maybe	⚠️ Slow	Maybe	Timeout-heavy	Technical user
Generic marketplace scraper	Medium	❌ Not Vinted-specific	Maybe	❌ Usually none	Varies	Data collector
Scheduled Vinted monitor	Medium	✅ Needed	✅ Core feature	✅ Required	Must be explicit	Reseller/operator

If the goal is daily reseller intelligence, the last row matters more than the prettiest one-time export.

✅ What a serious Vinted scraper needs

Requirement	Why
26-market support	Vinted is fragmented by country
Country cap	Prevent runaway multi-country jobs
`maxItems` cap	Prevent surprise bills
Persistent state	Required for price history and sell-through
Summary rows	Needed for webhook/Telegram/CSV workflows
Strict sold filtering	Avoid false sold rows
Clean failure rows	Do not corrupt history with bad data

🧪 Live data from my test batch

On June 4, 2026, I ran seven small cloud tests.

Mode	Run ID	Status	Rows	Duration	Free-tier estimated charge
`SEARCH`	`7BHS0mBNeN4faoDZk`	`SUCCEEDED`	8	10s	`$0.036`
`CROSS_COUNTRY`	`55PiTkUKZneTJo8Ep`	`SUCCEEDED`	1	86s	`$0.022`
`SELL_THROUGH_TRACKER` baseline	`gCd8a3kk4AC9yJWpI`	`SUCCEEDED`	9	6s	`$0.038`
`SELL_THROUGH_TRACKER` second pass	`sbCksMapWGd5GBG9O`	`SUCCEEDED`	2	5s	`$0.024`
`SOLD_ITEMS`	`wvFbmO0HscQits0UV`	`SUCCEEDED`	0	18s	`$0.020`
`SELLER_PROFILE`	`qJbKKIoxK0XiPifIO`	`SUCCEEDED`	1	41s	`$0.022`
`PRICE_TRACK`	`nWdbpqX2JKdZLs1ad`	`SUCCEEDED`	2	359s	`$0.024`

Total batch:

23 emitted rows
7 Actor starts
estimated Free-tier charge: $0.186

The price-track run is the outlier.

It hit several 403s, then browser fallback recovered one of two items.

That is why "works once" is not enough. You need to inspect failure behavior.

🧪 What each test proved

Mode	What it proved	What it did not prove
`SEARCH`	Can return fresh listing rows fast	That those listings are worth buying
`CROSS_COUNTRY`	Can emit a compact country comparison	That a spread is profit
`SELL_THROUGH_TRACKER` baseline	Can create a stateful watchlist	That items sold yet
`SELL_THROUGH_TRACKER` second pass	Can detect a missing item without overclaiming sold	That one missing run means sold
`SOLD_ITEMS`	Can return zero instead of false positives	That sold visibility is always available
`SELLER_PROFILE`	Can extract seller-level context	That the seller is worth monitoring
`PRICE_TRACK`	Can preserve history under partial extraction failure	That every item URL resolves fast

That is the kind of comparison I trust more than a "top 10 tools" list.

The failure cases are part of the product.

❌ Red flags when comparing tools

Claim	Why I distrust it
"Real-time opportunities"	Usually means polling. Ask about schedule cost.
"Guaranteed arbitrage"	Spread is not profit. Shipping, fees, condition, and demand matter.
"Sold item scraping"	Vinted often hides or changes sold visibility.
"Unlimited countries"	Usually means unstable or expensive runs.
"No blockers"	Datadome/Cloudflare behavior changes.

✅ What I trust more

I trust boring outputs like this:

{
  "priceUnavailable": true,
  "warning": "Current price could not be extracted; price history was not updated."
}

And this:

{
  "trackingStatus": "missing",
  "confidence": "low",
  "missingRuns": 1,
  "missingRunsThreshold": 2
}

Because they do not overclaim.

🧭 Decision tree

If I were choosing a Vinted scraper for a reseller, I would start with the workflow:

Do you need one export or recurring signals?

Then:

Need	Use
One manual lookup	Vinted website
One CSV export	`SEARCH`
Monitor a keyword every day	`SELL_THROUGH_TRACKER`
Watch one seller	`SELLER_PROFILE`
Watch exact listing prices	`PRICE_TRACK`
Compare countries	`CROSS_COUNTRY`
Prove sold state from explicit sold pages	`SOLD_ITEMS`, with caution

The wrong decision is trying to make one mode answer every question.

Example:

PRICE_TRACK is great for exact URLs.
PRICE_TRACK is bad for discovering new inventory.

And:

CROSS_COUNTRY is great for market direction.
CROSS_COUNTRY is not a profit calculator.

🧰 Inputs I would test before trusting any tool

I would run a small test batch before scheduling anything:

{
  "mode": "SEARCH",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 10,
  "includePhotos": false
}

Then:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 100,
  "trackingStoreName": "daily-af1-fr",
  "trackerId": "daily-af1-fr",
  "emitRunSummary": true
}

Then:

{
  "mode": "PRICE_TRACK",
  "itemUrls": [
    "https://www.vinted.fr/items/9089774198-nike-air-pegasus-volt-green-neon-eur42-hq5403-700"
  ],
  "trackingStoreName": "price-af1-shortlist"
}

If a tool cannot explain what each row means after those three tests, I would not schedule it.

💸 Cost guardrails

At the time of writing, Free-tier pricing was:

$0.020 / Actor start
$0.002 / result row

That means:

Emitted rows	Estimated charge
10	`$0.040`
100	`$0.220`
300	`$0.620`
300 daily for 30 days	`$18.60`

The trap is not one run.

The trap is scheduling a noisy monitor and forgetting it.

The other trap is misunderstanding "items inspected" versus "rows emitted".

Example from the live tests:

Run	Internal idea	Rows emitted	Estimated charge
`CROSS_COUNTRY`	5 countries x 3 listings	1	`$0.022`
`SELL_THROUGH_TRACKER` baseline	8 observed items + summary	9	`$0.038`
`SELL_THROUGH_TRACKER` second pass	Active items suppressed, summary kept	2	`$0.024`
`PRICE_TRACK`	2 exact URLs	2	`$0.024`

For schedules, I would always set:

maxItems
country list
includePhotos
emitActiveItems
trackingStoreName

Those five settings decide whether the workflow stays controlled.

🧱 Where Vinted Smart is not perfect

I do not want to hide the rough edges.

Area	Honest limitation	Safer behavior
`PRICE_TRACK`	One live run took `359s` under 403/fallback pressure	It preserved history and marked unavailable price
`SOLD_ITEMS`	The live test returned `0` rows	It avoided false sold rows
`CROSS_COUNTRY`	Spread is based on small samples	Treat as radar, not profit
Seller profile	A seller row does not prove opportunity	Use it as a filter
Scheduling	Too many noisy schedules can cost money	Start small and cap rows

I prefer an Actor that says:

I could not prove this.

over one that fills the dataset with confident-looking bad data.

✅ My scoring rubric

When comparing Vinted scraping tools, I would score like this:

Criterion	Weight	Why
Recurring workflow support	5/5	Daily use is where value compounds
State persistence	5/5	Required for price and sell-through history
Cost control	5/5	Schedules can run unattended
Country handling	4/5	Vinted markets differ
Clean failures	4/5	Bad alerts are worse than no alerts
Raw export size	2/5	Bigger CSV is not always better
Fancy UI	1/5	Nice, but not the core value

This is why I keep coming back to scheduled monitors instead of one-shot scrapers.

🏁 My recommendation

If you only need one manual lookup:

Use Vinted search.

If you need a one-time CSV:

Use SEARCH with maxItems capped.

If you need recurring reseller intelligence:

Start with SELL_THROUGH_TRACKER.

If you need exact listing alerts:

Use PRICE_TRACK on specific URLs.

If you need country spread:

Use CROSS_COUNTRY first, then schedule only the promising monitors.

🚀 Try the actor

The Actor is here:

https://apify.com/kazkn/vinted-smart-scraper?fpr=8fp2od

Start small:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 100,
  "trackingStoreName": "daily-nike-air-force-fr",
  "trackerId": "daily-nike-air-force-fr",
  "emitActiveItems": true,
  "emitRunSummary": true
}

Run once.

Inspect output.

Then schedule it.

Seller Watchlists, Price Drops, and Webhooks: The Vinted Signals I Actually Schedule

KazKN — Thu, 04 Jun 2026 21:19:08 +0000

After testing sell-through and country comparison, I wanted to check two smaller signals:

Seller profiles.
Exact listing price history.

Both are useful, but they are not equal.

Seller profiles are good for watchlists.

Price tracking is good for exact item URLs.

I ran both live on June 4, 2026 with Vinted Smart Scraper.

Disclosure: I built this Actor. Some Apify links may use my referral code.

🧠 Why these signals matter

Most Vinted automation starts with a broad search:

query -> results -> CSV

That is useful once.

But resellers eventually ask more specific questions:

Is this seller consistently interesting?
Did this exact item drop?
Did this watched item disappear?
Should I get alerted now or ignore it?

Those are not the same job.

That is why this part is about smaller signals.

They do not look as impressive as a big export, but they are the signals that make a scheduled workflow useful.

🧩 Seller profile is not item monitoring

Before the live run, I separated the workflows:

Workflow	Best signal	Bad use
Seller watchlist	Seller activity and profile stats	Exact price drops
Price tracking	Exact item URL history	Discovering new items
Sell-through tracker	Query/listing disappearance	Seller reputation
Sold-items page	Explicit sold evidence when available	Assuming every missing item is sold

This matters because a single "Vinted monitor" can easily become confusing.

The user should know what each mode is answering.

👤 Run 1: seller watchlist

The seller URL came from a real SEARCH output:

{
  "mode": "SELLER_PROFILE",
  "sellerUrls": [
    "https://www.vinted.fr/member/3146082883-adwatches"
  ],
  "maxItems": 1,
  "includePhotos": false,
  "maxConcurrency": 1,
  "requestDelayMs": 500
}

Live result:

Field	Value
Run ID	`qJbKKIoxK0XiPifIO`
Dataset ID	`C9v2k3RMb6C3nP3yQ`
Status	`SUCCEEDED`
Duration	`41s`
Rows emitted	`1`
Free-tier estimated charge	`$0.022`

Output:

{
  "id": 3146082883,
  "username": "adwatches",
  "profileUrl": "https://www.vinted.fr/member/3146082883-adwatches",
  "rating": 1,
  "ratingCount": 11,
  "itemCount": 1,
  "soldItemCount": 14,
  "followerCount": 3,
  "country": "fr",
  "lastSeenAt": "2026-06-04T22:11:32+02:00",
  "verifications": {
    "email": true,
    "phone": false,
    "facebook": false,
    "google": true
  }
}

🔍 What this profile tells me

This row is not an "opportunity" by itself.

It is a filter.

Field	Live value	How I use it
`rating`	`1`	Weak trust signal, inspect manually
`ratingCount`	`11`	Enough history to avoid treating it as brand new
`itemCount`	`1`	Not currently a large active inventory
`soldItemCount`	`14`	Some past sales activity
`followerCount`	`3`	Not a high-demand seller profile
`phone` verified	`false`	Not a blocker, but useful context
`google` verified	`true`	Basic identity signal

For this seller, I would not build a high-frequency monitor.

I might still watch exact item URLs if the listing itself looks underpriced.

That is the point: profile data helps decide where not to spend monitoring budget.

✅ When seller monitoring helps

Question	Mode
Does this seller keep listing relevant inventory?	`SELLER_PROFILE`
Did their shop count change?	`SELLER_PROFILE`
Did watched items disappear?	`SELL_THROUGH_TRACKER` with item URLs
Did an exact listing price drop?	`PRICE_TRACK`

I would not schedule seller profile checks every 5 minutes.

Daily is usually enough unless you are monitoring a very specific seller.

📅 Seller watchlist templates

Small daily seller check:

{
  "mode": "SELLER_PROFILE",
  "sellerUrls": [
    "https://www.vinted.fr/member/3146082883-adwatches"
  ],
  "maxItems": 1,
  "includePhotos": false,
  "maxConcurrency": 1,
  "requestDelayMs": 500
}

Seller shortlist after a search run:

{
  "mode": "SELLER_PROFILE",
  "sellerUrls": [
    "https://www.vinted.fr/member/3146082883-adwatches",
    "https://www.vinted.fr/member/123456-example"
  ],
  "maxItems": 10,
  "includePhotos": false
}

What I would send to Telegram:

Seller adwatches: 1 active item, 14 sold items, rating 1/5 from 11 reviews, last seen 2026-06-04.

That is enough for a reseller to decide whether to click.

💸 Run 2: exact listing price tracking

For PRICE_TRACK, I used two real item URLs from the search run:

{
  "mode": "PRICE_TRACK",
  "itemUrls": [
    "https://www.vinted.fr/items/9089776821-nike-air-force-1-shadow-unisex-numero-45",
    "https://www.vinted.fr/items/9089774198-nike-air-pegasus-volt-green-neon-eur42-hq5403-700"
  ],
  "trackingStoreName": "devto-series-price-track-2026-06-04",
  "maxConcurrency": 1,
  "requestDelayMs": 500
}

Live result:

Field	Value
Run ID	`nWdbpqX2JKdZLs1ad`
Dataset ID	`TkFl0ztR6QMXa65MM`
Status	`SUCCEEDED`
Duration	`359s`
Rows emitted	`2`
Free-tier estimated charge	`$0.024`

This run was slow because Vinted returned several 403s.

That is the interesting part.

From the run log:

Browser price fallback failed for item 9089776821: timed out after 30000ms
Price unavailable for item 9089776821; history not updated
Resolved item 9089774198 price through browser fallback
Price tracked for item 9089774198: 39.99 EUR (0% drop)

This is exactly the kind of boring log I want in a scraper.

Not because timeouts are good.

Because the Actor did not corrupt the price history when extraction failed.

🛡️ The important fallback

For the first item, price extraction failed.

The Actor returned:

{
  "itemId": 9089776821,
  "currentPrice": null,
  "currency": "EUR",
  "priceHistory": [],
  "priceDropPct": 0,
  "priceUnavailable": true,
  "warning": "Current price could not be extracted; price history was not updated."
}

That is the right failure mode.

Failure	Bad behavior	Safer behavior
Price blocked once	❌ Write `0` into history	✅ Mark `priceUnavailable`
Browser fallback times out	❌ Delete previous history	✅ Keep history clean
API returns 403	❌ Crash whole watchlist	✅ Continue to next item

For the second item, the browser fallback worked:

{
  "itemId": 9089774198,
  "currentPrice": 39.99,
  "currency": "EUR",
  "priceHistory": [
    {
      "price": 39.99,
      "date": "2026-06-04T20:27:02.852Z"
    }
  ],
  "priceDropPct": 0
}

The log confirmed it:

Resolved item 9089774198 price through browser fallback
Price tracked for item 9089774198: 39.99 EUR (0% drop)

📊 Two rows, two different meanings

Both rows came from the same run, but they should trigger different actions:

Item	Result	Action
`9089776821`	`priceUnavailable: true`	Keep previous history, retry later
`9089774198`	`currentPrice: 39.99`	Store history point, compute future drops

This distinction is important for alerts.

If a scraper treats "blocked once" as "price is zero", every downstream alert becomes garbage.

For a real watchlist, I want this rule:

No extracted price = no price-history mutation

That is less exciting than a fake discount alert, but it is much safer.

🧾 Persistent price tracking contract

The trackingStoreName is the anchor:

{
  "trackingStoreName": "devto-series-price-track-2026-06-04"
}

Use one stable store name per watchlist.

Store naming style	Good?	Why
`daily-af1-watchlist-fr`	✅	Stable and specific
`seller-adwatches-watchlist`	✅	Seller-scoped
`test`	❌	Easy to reuse by accident
`price-track`	❌	Too broad
New random name every run	❌	No persistent history

The store name is what turns a run into a history.

Without it, you are just re-scraping the current price.

🔔 Webhook shape

For scheduled alerts, I would not send the full dataset every time.

I would send a compact payload like:

{
  "workflow": "vinted-price-watchlist",
  "itemId": 9089774198,
  "currentPrice": 39.99,
  "priceDropPct": 0,
  "priceUnavailable": false,
  "runId": "nWdbpqX2JKdZLs1ad"
}

Or for unavailable prices:

{
  "workflow": "vinted-price-watchlist",
  "itemId": 9089776821,
  "priceUnavailable": true,
  "action": "do_not_update_history"
}

For Telegram, I would keep it even shorter:

Vinted price watch: 9089774198 still at 39.99 EUR. No drop yet.

And for a failed extraction:

Vinted price watch: 9089776821 price unavailable. History not changed.

The second message is not glamorous, but it prevents bad decisions.

💸 Cost and scheduling guardrails

The live PRICE_TRACK run emitted 2 rows.

At the Free pricing available when I ran it:

$0.020 / Actor start
$0.002 / result row

The estimated charge was:

$0.020 + (2 * $0.002) = $0.024

The bigger risk is time, not just row cost.

This run took 359s because of fallback behavior.

So I would not schedule a huge exact-URL watchlist every few minutes.

Watchlist size	Cadence I would start with	Why
1-5 exact URLs	Every few hours	Acceptable if items are high-value
5-20 exact URLs	Daily	Better balance
20-100 URLs	Daily/weekly split	Avoid one slow run blocking everything
Broad discovery	Use `SELL_THROUGH_TRACKER` instead	Exact URLs are the wrong tool

✅ Alert rules I would trust

For price tracking:

Condition	Alert?
`priceDropPct > 10`	✅
`priceUnavailable: true` once	❌
`priceUnavailable: true` multiple times	Maybe, as a health warning
New price history point, no drop	❌
Exact watched item disappears	Use sell-through/missing logic

For seller watchlists:

Condition	Alert?
Active item count jumps	✅
Seller appears in a profitable query repeatedly	✅
Rating count changes	Maybe
Last seen changes	Usually no

The goal is not more alerts.

The goal is fewer, better alerts.

✅ What I would schedule

Workflow	Schedule	Why
Seller profile	Daily	Slow enough, useful for seller watchlists
Price track 5-20 exact URLs	Daily	Good for item-specific monitoring
Sell-through query	Daily or every few hours	Best market movement signal
Sold explicit pages	Only when needed	Can return zero by design

🚀 Try it

Run the Actor here:

https://apify.com/kazkn/vinted-smart-scraper?fpr=8fp2od

For price tracking, the rule is:

one watchlist = one stable trackingStoreName

Do not reuse the same store for unrelated item groups unless you intentionally want those histories together.

Cross-Country Vinted Search: Comparing 5 Markets Without Burning Sessions

KazKN — Thu, 04 Jun 2026 21:17:03 +0000

In Part 1, I showed why a Vinted monitor should track what changes, not just what exists.

This part is about a different problem:

What happens when the same query behaves differently across countries?

I ran this live on June 4, 2026 with Vinted Smart Scraper.

Disclosure: I built this Actor. Some Apify links may use my referral code.

🧨 The mistake I almost made

The first tempting version of this feature was simple:

scrape 5 countries -> pick cheapest -> pick most expensive -> call it arbitrage

That looks good in a screenshot, but it is not how reselling works.

A nike air force 1 listing in France and a nike air force 1 listing in Germany can differ by:

Difference	Why it matters
Size	EUR 35 and EUR 45 are not the same market
Condition	"Good" can hide heavy wear
Photos	Some listings are underpriced because they look bad
Seller reliability	A cheap item from a weak seller is not always an opportunity
Shipping	Country spread can disappear after fees
Demand	A high listing price does not mean buyers pay it

So I do not want a fake "profit bot".

I want a country radar:

Where should I spend my monitoring budget today?

That is the correct job for CROSS_COUNTRY.

🌍 The input

{
  "mode": "CROSS_COUNTRY",
  "query": "nike air force 1",
  "countries": ["fr", "de", "es", "it", "nl"],
  "condition": ["very_good", "good"],
  "priceMin": 20,
  "priceMax": 120,
  "sortBy": "newest_first",
  "maxItems": 15,
  "includePhotos": false,
  "maxConcurrency": 1,
  "requestDelayMs": 500
}

I intentionally kept it small:

Setting	Why
`5` countries	Current stability cap
`15` max items	3 items per country
`includePhotos: false`	Smaller output
`maxConcurrency: 1`	Slow but clean for a proof run

✅ Live result

Field	Value
Run ID	`55PiTkUKZneTJo8Ep`
Dataset ID	`9I2fifqjEv9sQBmrg`
Status	`SUCCEEDED`
Duration	`86s`
Dataset rows emitted	`1`
Free-tier estimated charge	`$0.022`

Why only one row?

Because CROSS_COUNTRY emits a comparison object instead of 15 individual listing rows.

That output shape is intentional.

If the Actor emitted every country listing as a normal row, a small five-country radar would quickly become noisy:

Output style	What you get	Problem
15 item rows	Raw listings from all countries	Harder to read in a webhook
5 country rows	One row per market	Better, but still requires aggregation
1 comparison row	Best buy/sell country + spread + table	Useful for scheduled decisions

For a recurring monitor, I care less about dumping every listing and more about answering:

Did the country spread become interesting enough to open a deeper monitor?

📊 Output

{
  "query": "nike air force 1",
  "bestBuyCountry": "fr",
  "bestSellCountry": "de",
  "arbitrageSpreadPct": 47.4,
  "comparisons": [
    {
      "country": "fr",
      "avgPrice": 31.66,
      "medianPrice": 30,
      "minPrice": 25,
      "maxPrice": 39.99,
      "itemCount": 3,
      "currency": "EUR"
    },
    {
      "country": "de",
      "avgPrice": 46.67,
      "medianPrice": 50,
      "minPrice": 30,
      "maxPrice": 60,
      "itemCount": 3,
      "currency": "EUR"
    },
    {
      "country": "es",
      "avgPrice": 31.66,
      "medianPrice": 30,
      "minPrice": 25,
      "maxPrice": 39.99,
      "itemCount": 3,
      "currency": "EUR"
    },
    {
      "country": "it",
      "avgPrice": 31.66,
      "medianPrice": 30,
      "minPrice": 25,
      "maxPrice": 39.99,
      "itemCount": 3,
      "currency": "EUR"
    },
    {
      "country": "nl",
      "avgPrice": 41.67,
      "medianPrice": 30,
      "minPrice": 30,
      "maxPrice": 65,
      "itemCount": 3,
      "currency": "EUR"
    }
  ]
}

Full country table from the run:

Country	Items	Min	Median	Avg	Max
`fr`	3	`25`	`30`	`31.66`	`39.99`
`de`	3	`30`	`50`	`46.67`	`60`
`es`	3	`25`	`30`	`31.66`	`39.99`
`it`	3	`25`	`30`	`31.66`	`39.99`
`nl`	3	`30`	`30`	`41.67`	`65`

🧪 What the run actually proved

The useful part is not "Germany is profitable".

The useful part is:

Signal	What I can say	What I cannot say
France median was `30`	France looked cheaper in this small sample	Every French AF1 listing is cheap
Germany median was `50`	Germany looked higher in this sample	German buyers will pay more
Spread was `47.4%`	The query is worth deeper monitoring	Net resale profit is `47.4%`
Five countries finished successfully	The workflow handled country redirects	It will always finish at the same speed
One dataset row was emitted	Schedule output is compact	Internal scraping was only one request

This distinction matters because a reseller does not need another messy spreadsheet.

They need a short list of where to look next.

⚙️ Why cross-country scraping is harder than it looks

Vinted is not one global marketplace with one clean catalog.

It behaves more like a group of country-specific markets that share branding but do not always behave the same way from a scraper perspective.

Technical issue	Practical effect
Country redirects	A request can land on the wrong country if session handling is weak
Different localized pages	The same query can expose slightly different metadata
Anti-bot variance	One country can be easy while another slows the whole run
Ranking drift	`newest_first` today is not the same as tomorrow
Result caps	A high `maxItems` across countries can multiply quickly
Currency/fees/shipping	EUR price comparison is only the first layer

That is why I kept this test at:

5 countries
3 items per country
1 emitted comparison row
86 seconds total

It is not the maximum possible configuration.

It is a clean proof that the workflow can survive a small scheduled country radar.

✅ What this is good for

Use case	Good fit?
Quick market spread check	✅
Comparing the same query across countries	✅
Building a shortlist of countries to monitor daily	✅
Proving actual resale profit	❌
Replacing human judgment	❌

The output says:

Best buy country: fr
Best sell country: de
Spread: 47.4%

That is not a profit guarantee.

It is a signal that this query may be worth monitoring more carefully.

⚠️ The hidden trap

The dangerous version of this feature would be:

"Here is a profitable arbitrage gap."

That would be sloppy.

The safer version is:

"Here is a price spread from a small sample. Validate shipping, sizes, condition, fees, and actual sell-through before trusting it."

Signal	Still missing
Country-level price spread	Shipping and buyer behavior
Median/min/max	Listing quality
5-country snapshot	Time-series confidence
Query-level comparison	Exact product matching

🧭 The decision loop I would use

I would not schedule CROSS_COUNTRY as the final monitor.

I would use it as step one:

cross-country radar -> pick promising country -> sell-through tracker -> exact item watchlist

Example:

Step	Mode	Goal
1	`CROSS_COUNTRY`	Find which markets are unusually cheap/expensive
2	`SELL_THROUGH_TRACKER`	Check if inventory actually disappears
3	`PRICE_TRACK`	Watch exact URLs that are close to a buy decision
4	Webhook/Telegram/CSV	Push only useful signals

The important part is that every step narrows the search space.

That is how you avoid turning a reseller tool into a bill generator.

🔁 Schedule templates

Small daily country radar:

{
  "mode": "CROSS_COUNTRY",
  "query": "nike air force 1",
  "countries": ["fr", "de", "es", "it", "nl"],
  "condition": ["very_good", "good"],
  "priceMin": 20,
  "priceMax": 120,
  "sortBy": "newest_first",
  "maxItems": 100,
  "includePhotos": false,
  "maxConcurrency": 1,
  "requestDelayMs": 500
}

Weekly wider radar:

{
  "mode": "CROSS_COUNTRY",
  "query": "adidas spezial",
  "countries": ["fr", "de", "es", "it", "nl"],
  "condition": ["new_with_tags", "very_good", "good"],
  "priceMin": 15,
  "priceMax": 150,
  "sortBy": "newest_first",
  "maxItems": 300,
  "includePhotos": false
}

Handoff to sell-through when a country keeps showing spreads:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 100,
  "trackingStoreName": "daily-af1-fr-after-cross-country",
  "trackerId": "daily-af1-fr-after-cross-country",
  "emitRunSummary": true,
  "emitActiveItems": true
}

💸 Cost guardrail

The live proof run emitted 1 row.

At the Free pricing available when I ran the test:

$0.020 / Actor start
$0.002 / result row

That makes the live run roughly:

$0.020 + (1 * $0.002) = $0.022

Important nuance:

maxItems controls how much the Actor is allowed to inspect
dataset rows control the result-row charge

So a compact comparison output is useful for schedules, but you still need sane maxItems and country caps.

My default:

Frequency	Suggested cap	Why
First manual test	`15`	Fast proof
Daily radar	`100`	Enough signal, still controlled
Weekly scan	`300`	Wider sample without making it permanent
Always-on high frequency	Avoid	Use sell-through or exact watchlists instead

🔁 How I would schedule it

Use this weekly or daily:

{
  "mode": "CROSS_COUNTRY",
  "query": "nike air force 1",
  "countries": ["fr", "de", "es", "it", "nl"],
  "maxItems": 100,
  "sortBy": "newest_first"
}

Then use SELL_THROUGH_TRACKER for the countries that repeatedly look interesting.

My rule:

CROSS_COUNTRY = find where to look
SELL_THROUGH_TRACKER = learn what moves
PRICE_TRACK = watch exact item URLs

🔔 Webhook payload I would actually send

If I schedule this every day, I do not want the full dataset in Telegram.

I want a compact message:

{
  "workflow": "vinted-cross-country-radar",
  "query": "nike air force 1",
  "bestBuyCountry": "fr",
  "bestSellCountry": "de",
  "arbitrageSpreadPct": 47.4,
  "sampleSize": {
    "fr": 3,
    "de": 3,
    "es": 3,
    "it": 3,
    "nl": 3
  },
  "action": "open-sell-through-tracker-for-fr"
}

That is the difference between scraping and monitoring.

Scraping gives you rows.

Monitoring tells you what to do next.

🚀 Try it

Run the Actor here:

https://apify.com/kazkn/vinted-smart-scraper?fpr=8fp2od

Start with maxItems: 100.

If the comparison is useful, save it as an Apify Task and schedule it.

I Built a Vinted Monitor That Tracks What Disappears, Not Just What Exists

KazKN — Thu, 04 Jun 2026 21:17:02 +0000

A normal Vinted search tells you what exists right now.

A reseller usually needs the opposite:

What changed since yesterday?

That sounds like a small difference, but it changes the whole scraper design.

One-off exports are easy. Scheduled market monitoring is not. You need stable inputs, a persistent state store, clean diffs, cost caps, and a way to avoid calling every missing item "sold" when Vinted simply changed ranking or hid a page.

I ran this live on Apify on June 4, 2026 with Vinted Smart Scraper.

Disclosure: I built this Actor. Some Apify links may use my referral code.

📊 The live baseline

Before changing the article, I pulled the real public Store and run data.

Metric	Value
Actor	`kazkn/vinted-smart-scraper`
Actor ID	`4UAPrwZb1XOlkCJKK`
Supported Vinted markets	`26`
Countries per run cap	`5`
Total public runs	`108,367`
Total users	`464`
Users, 7 days	`31`
Users, 30 days	`97`
Runs, 30 days	`7,392`
Succeeded runs, 30 days	`7,166`
Rating	`5.0 / 5`
Reviews	`4`

Current Free-tier event pricing at the time of the test:

$0.020 per Actor start
$0.002 per dataset result

So the billing guardrail is simple:

estimated charge = actor start + emitted rows * result price

❌ The wrong abstraction

My first mistake was thinking like this:

"Users need a Vinted scraper."

That is too broad.

Resellers do not only need raw listings. They need a repeatable signal.

❌ One-time scraper	✅ Market monitor
Export one CSV	Run the same input every day
Count active listings	Compare snapshots
Trust hidden sold pages	Track `missing`, `likely_sold`, `reappeared`
Pull everything	Cap rows with `maxItems`
Pay for noisy rows	Emit only changes after baseline
Debug manually	Send summary rows to CSV/API/webhook

That is why the most important mode is not the normal SEARCH.

It is SELL_THROUGH_TRACKER.

🧪 Run 1: normal search

I started with a tiny real search:

{
  "mode": "SEARCH",
  "query": "nike air force 1",
  "countries": ["fr"],
  "condition": ["very_good", "good"],
  "priceMin": 20,
  "priceMax": 120,
  "sortBy": "newest_first",
  "maxItems": 8,
  "includePhotos": false,
  "includeSellerDetails": false
}

Result:

Field	Value
Run ID	`7BHS0mBNeN4faoDZk`
Dataset ID	`DQGMfYNvIQabnV2wF`
Status	`SUCCEEDED`
Duration	`10s`
Rows emitted	`8`
Total available in Vinted response	`960`
Free-tier estimated charge	`$0.036`

Sample output:

{
  "id": 9089776821,
  "title": "Nike air force 1 shadow unisex numero 45",
  "url": "https://www.vinted.fr/items/9089776821-nike-air-force-1-shadow-unisex-numero-45",
  "price": 30,
  "currency": "EUR",
  "brand": "Air Force",
  "size": "45",
  "condition": "Bon état",
  "country": "fr",
  "seller": {
    "id": 3160438769,
    "username": "eeeeeeed1"
  }
}

That is useful, but it is still just a snapshot.

The more interesting question is:

What happens if I run the same thing again?

✅ Run 2: build a sell-through baseline

Here is the baseline input:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "condition": ["very_good", "good"],
  "priceMin": 20,
  "priceMax": 120,
  "sortBy": "newest_first",
  "maxItems": 8,
  "trackingStoreName": "devto-series-sell-through-2026-06-04",
  "trackerId": "devto-nike-air-force-fr-2026-06-04",
  "missingRunsThreshold": 2,
  "emitActiveItems": true,
  "emitRunSummary": true
}

The important fields:

Field	Why it matters
`trackingStoreName`	Keeps state across scheduled runs
`trackerId`	Stable ID for this monitor
`missingRunsThreshold`	Reduces false sold signals
`emitActiveItems`	Full baseline first, lighter output later
`emitRunSummary`	Adds one daily summary row for automations

Live result:

Field	Value
Run ID	`gCd8a3kk4AC9yJWpI`
Dataset ID	`0QbscZ6GRdhmOlSqx`
Status	`SUCCEEDED`
Duration	`6s`
Rows emitted	`9`
Item rows	`8`
Summary rows	`1`
Free-tier estimated charge	`$0.038`

The summary row is what turns the Actor into a daily monitor:

{
  "recordType": "SELL_THROUGH_DAILY_SUMMARY",
  "trackerId": "devto-nike-air-force-fr-2026-06-04",
  "isBaseline": true,
  "scheduleReady": true,
  "observedItems": 8,
  "outputItemRecords": 8,
  "totalTrackedItems": 8,
  "newItems": 8,
  "activeItems": 8,
  "missingItems": 0,
  "likelySoldItems": 0,
  "explicitSoldItems": 0,
  "sellThroughRate": 0,
  "avgPrice": 35,
  "topBrands": [
    { "brand": "Air Force", "count": 5 },
    { "brand": "Nike", "count": 3 }
  ]
}

The baseline does not prove anything sold yet.

It creates the memory needed for the next run.

🔁 Run 3: same tracker, lighter scheduled output

For the second run, I kept the same trackingStoreName and trackerId, but changed one thing:

{
  "emitActiveItems": false
}

Full input:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "condition": ["very_good", "good"],
  "priceMin": 20,
  "priceMax": 120,
  "sortBy": "newest_first",
  "maxItems": 8,
  "trackingStoreName": "devto-series-sell-through-2026-06-04",
  "trackerId": "devto-nike-air-force-fr-2026-06-04",
  "missingRunsThreshold": 2,
  "emitActiveItems": false,
  "emitRunSummary": true
}

Live result:

Field	Value
Run ID	`sbCksMapWGd5GBG9O`
Dataset ID	`55gRHqbUbiqnmT6O3`
Status	`SUCCEEDED`
Duration	`5s`
Rows emitted	`2`
Item rows	`1`
Summary rows	`1`
Free-tier estimated charge	`$0.024`

That second run found:

{
  "recordType": "SELL_THROUGH_DAILY_SUMMARY",
  "isBaseline": false,
  "observedItems": 8,
  "outputItemRecords": 1,
  "totalTrackedItems": 9,
  "newItems": 1,
  "activeItems": 8,
  "missingItems": 1,
  "likelySoldItems": 0,
  "explicitSoldItems": 0,
  "newlyMissingItems": 1,
  "dailySellThroughSignals": 0,
  "avgPrice": 34.38
}

One item was not observed on the second run:

{
  "recordType": "SELL_THROUGH_ITEM",
  "itemId": 9089774198,
  "title": "Nike Air Pegasus Volt Green Neon - EUR42 - HQ5403-700",
  "trackingStatus": "missing",
  "changeType": "missing",
  "confidence": "low",
  "lastSeenPrice": 39.99,
  "missingRuns": 1,
  "missingRunsThreshold": 2
}

Notice the important part:

missingRuns: 1
missingRunsThreshold: 2
confidence: low
likelySoldItems: 0

The Actor did not call this sold after one missing run.

That is intentional.

🧠 Why I do not trust sold pages blindly

I also ran SOLD_ITEMS on the same query:

{
  "mode": "SOLD_ITEMS",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 5
}

Live result:

Field	Value
Run ID	`wvFbmO0HscQits0UV`
Status	`SUCCEEDED`
Rows emitted	`0`
Free-tier estimated charge	`$0.020`

The log showed the reason:

Sold-items endpoint variants returned active listings only.
Returning no rows instead of false sold items.

That is exactly the kind of boring defensive behavior I want.

Situation	Bad scraper behavior	Safer behavior
Vinted returns active listings from a sold endpoint	❌ Mark active items as sold	✅ Return zero rows
Item disappears for one run	❌ Claim it sold	✅ Mark `missing`, low confidence
Item stays missing across runs	✅ Increase confidence	✅ Use `missingRunsThreshold`

🖼️ Snapshot diff visual

The mental model is:

baseline snapshot
       ↓
scheduled snapshot
       ↓
diff engine
       ↓
daily summary row + item-level changes

For a webhook or Telegram bot, the useful object is not every listing.

It is the summary:

{
  "telegramText": "Vinted sell-through devto-nike-air-force-fr-2026-06-04: 8 observed, 1 first seen, likely sold: 0, sold: 0, reappeared: 0."
}

💸 Cost guardrails

With current Free-tier event pricing:

start = $0.020
row = $0.002

The test charges would be:

Run	Rows	Estimated Free-tier charge
Search snapshot	8	`$0.036`
Sell-through baseline	9	`$0.038`
Scheduled second pass	2	`$0.024`
Sold explicit check	0	`$0.020`

The practical rule:

Workflow	First run	Scheduled run
Inspect all current inventory	✅ `emitActiveItems: true`	❌ usually too noisy
Daily changes only	❌ not enough baseline	✅ `emitActiveItems: false`
Webhook / Telegram	✅ keep `emitRunSummary: true`	✅ keep `emitRunSummary: true`

Start with maxItems: 100.

Only move to 300 after one run proves the query is useful.

⚠️ Limits

This is not magic.

Claim	Reality
"Missing means sold"	❌ No. Missing can mean hidden, removed, reranked, moderated, or sold.
"Sold pages are always reliable"	❌ Not in my tests. Some endpoint variants returned active listings.
"More countries is always better"	❌ Current cap is 5 countries per run for stability.
"Schedule everything hourly"	❌ You pay per start and per emitted row. Start daily.
"This guarantees profit"	❌ It only gives better market data.

🚀 Try the exact monitor

Open Vinted Smart Scraper on Apify.

Use this first:

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air force 1",
  "countries": ["fr"],
  "maxItems": 100,
  "trackingStoreName": "daily-nike-air-force-fr",
  "trackerId": "daily-nike-air-force-fr",
  "missingRunsThreshold": 2,
  "emitActiveItems": true,
  "emitRunSummary": true
}

Run it once.

Then save it as an Apify Task, add a Schedule, and switch:

{
  "emitActiveItems": false
}

That is the difference between scraping Vinted once and monitoring a resale market every day.

📚 Series

This is Part 1 of Vinted Smart Scraper - Market Monitor.

Part 2: Cross-Country Vinted Search: Comparing 5 Markets Without Burning Sessions
Part 3: Seller Watchlists, Price Drops, and Webhooks: The Vinted Signals I Actually Schedule
Part 4: Best Vinted Scraper in 2026: An Honest Developer Comparison

How to Track Vinted Price Drops Automatically in 2026

KazKN — Mon, 01 Jun 2026 00:52:43 +0000

Most Vinted scraping workflows are one-shot exports.

You run a search, download a CSV, and then the data starts getting old.

That is fine if you only need a snapshot. It is not enough if you are a reseller, pricing analyst, or automation builder trying to answer one daily question:

Did this listing get cheaper since yesterday?

That is why I updated Vinted Smart Scraper so PRICE_TRACK can keep real price history across scheduled runs.

🧠 What changed

PRICE_TRACK now writes item price history to a named Apify key-value store.

In practice, that means you can:

Paste one or more Vinted item URLs.
Set a stable trackingStoreName.
Save the input as an Apify Task.
Schedule it daily.
Get priceHistory and priceDropPct every time it runs.

The important part is the stable store name. If you keep the same trackingStoreName, the Actor keeps reading and updating the same history instead of starting from zero on every run.

💸 Why this matters for resellers

Vinted prices move quietly.

A seller lists a Nike Air Force 1 at 45 EUR. Two days later it drops to 38 EUR. A week later it drops to 32 EUR. If you only search manually, you probably miss the timing.

Persistent price tracking turns that into a daily signal:

Signal	What it tells you	Action
`currentPrice` changed	The seller moved the price	Re-check margin
`priceDropPct` increased	The item may be easier to negotiate	Add to buy list
`daysListed` grows	Supply is not moving fast	Lower resale confidence
`priceHistory` stays flat	Seller is holding price	Wait or ignore

This is not an auto-buying bot. It does not buy, message, or manipulate Vinted. It gives you structured public listing data so you can make better pricing decisions.

⚙️ The input

Here is the smallest useful PRICE_TRACK setup:

{
  "mode": "PRICE_TRACK",
  "itemUrls": [
    "https://www.vinted.fr/items/8140955190-air-force-1",
    "https://www.vinted.fr/items/8092158420-nike-air-force"
  ],
  "trackingStoreName": "nike-air-force-price-history"
}

The rule is simple:

One monitoring workflow = one stable trackingStoreName.

If you track Nike Air Force 1 listings, use something like nike-air-force-price-history.

If you track Carhartt jackets, use another store like carhartt-detroit-price-history.

Do not reuse the same store for unrelated watchlists unless you intentionally want those histories together.

📊 The output

Each tracked listing returns a row like this:

{
  "itemId": 9055843802,
  "url": "https://www.vinted.fr/items/9055843802-scarpe-nike-air-force-1-bianche-455",
  "currentPrice": 14,
  "currency": "EUR",
  "priceHistory": [
    {
      "price": 14,
      "date": "2026-05-31T22:36:29.760Z"
    }
  ],
  "priceDropPct": 0,
  "daysListed": null
}

After later scheduled runs, the same item can build a longer history:

{
  "itemId": 9055843802,
  "currentPrice": 11,
  "currency": "EUR",
  "priceHistory": [
    { "price": 14, "date": "2026-05-31T22:36:29.760Z" },
    { "price": 11, "date": "2026-06-03T08:00:00.000Z" }
  ],
  "priceDropPct": 21.4
}

That is the difference between "scraping Vinted" and running a daily market monitor.

🛡️ What happens if Vinted blocks a price once

This was the important reliability fix.

If a run cannot extract the current price, the Actor does not write 0 into your price history.

Instead, the row is marked as unavailable and the history is left clean:

{
  "itemId": 9055843802,
  "currentPrice": 14,
  "priceHistory": [
    { "price": 14, "date": "2026-05-31T22:36:29.760Z" }
  ],
  "priceUnavailable": true,
  "warning": "Current price could not be extracted; price history was not updated."
}

That matters because one temporary extraction failure should not destroy your price chart.

🗓️ How to schedule it

The workflow is:

Open Vinted Smart Scraper on Apify.
Select PRICE_TRACK.
Paste the item URLs you want to monitor.
Set trackingStoreName.
Save the input as an Apify Actor Task.
Add an Apify Schedule to run it daily.

For most reseller workflows, daily is enough. Hourly price tracking can be useful for high-value items, but it also creates more run starts and more rows.

💰 Cost example

The current public pricing is pay-per-event:

Watchlist size	Rows per run	Approx Free-tier cost per daily run	Approx 30-day cost
1 item	1 row	about $0.022	about $0.66
10 items	10 rows	about $0.040	about $1.20
100 items	100 rows	about $0.220	about $6.60

That includes the current Free-tier start fee plus result rows. Higher Apify Store tiers reduce the per-result and start-event prices.

The billing guardrail is simple: the number of item URLs roughly controls the number of output rows.

🔁 When to use PRICE_TRACK vs SELL_THROUGH_TRACKER

Use PRICE_TRACK when you care about specific listing URLs.

Use SELL_THROUGH_TRACKER when you care about a whole search market: Nike Air Force 1 in France, Carhartt jackets in Germany, Adidas Campus across five countries, and so on.

Need	Best mode
Watch 20 exact item URLs	`PRICE_TRACK`
Detect if items disappear over time	`SELL_THROUGH_TRACKER`
Track competitor seller inventory	`SELLER_PROFILE` or `SELL_THROUGH_TRACKER`
Compare country-level price spreads	`CROSS_COUNTRY`

The strongest reseller setup is often both:

SELL_THROUGH_TRACKER to find which niches move.
PRICE_TRACK to monitor the exact listings you might buy.

✅ FAQ

Does PRICE_TRACK persist forever?

It persists across runs as long as you keep the same trackingStoreName and do not delete the Apify key-value store. Change the store name and you are intentionally starting a new history.

Can I export price history to CSV?

Yes. The Actor outputs dataset rows that can be exported through Apify as JSON, CSV, Excel, XML, or RSS using the platform export options and API.

Does this work for all 26 supported Vinted markets?

Yes. Vinted Smart Scraper supports 26 Vinted markets, including France, Germany, the United Kingdom, Italy, Spain, the Netherlands, Poland, Portugal, Belgium, Austria, Lithuania, Czech Republic, Slovakia, Hungary, Romania, Croatia, Finland, Denmark, Sweden, Estonia, Greece, Ireland, Luxembourg, Latvia, Slovenia, and the United States.

Can I run this without coding?

Yes. You can create a free account on Apify, open the Actor, paste your item URLs, save a task, and schedule it from the UI.

🚀 Try it

If you already use Vinted data for sourcing, price checks, or arbitrage, this turns a manual spreadsheet habit into a daily signal.

Start with 5 to 20 item URLs, schedule it daily, and let the history build for a week.

Then look at the price drops.

Vinted sold listings are unreliable. I added a sell-through tracker instead.

KazKN — Sat, 30 May 2026 21:43:43 +0000

If you are trying to understand demand on Vinted, "sold listings" are the obvious place to start.

The problem: Vinted often hides sold listings from public search results. Sometimes an item disappears because it sold. Sometimes it was deleted, moderated, relisted, reserved, or temporarily hidden. If a scraper pretends all disappeared listings are confirmed sales, the output looks useful but the signal is weak.

That is why I changed the approach in Vinted Smart Scraper: the main demand feature is now SELL_THROUGH_TRACKER, not classic sold-listing scraping.

How the tracker works

SELL_THROUGH_TRACKER compares snapshots over time.

First run:

Search a niche, brand, keyword, country, or price band
Save every active item into a named tracking store
Treat this as the baseline

Next runs:

Search the same query again
Compare the current result set to the previous snapshot
Mark each item as active, missing, likely_sold, sold, or reappeared

This gives you a sell-through signal without pretending Vinted exposes a clean sold-items API.

Example input

{
  "mode": "SELL_THROUGH_TRACKER",
  "query": "nike air max",
  "countries": ["fr"],
  "maxItems": 50,
  "trackingStoreName": "nike-air-max-fr-tracker",
  "missingRunsThreshold": 2
}

Run it daily with an Apify schedule. Keep the same trackingStoreName. After a few runs, you can see which items stay active, which disappear, and which disappear consistently enough to be treated as likely sold.

You can also track specific URLs:

{
  "mode": "SELL_THROUGH_TRACKER",
  "itemUrls": [
    "https://www.vinted.fr/items/8140955190-air-force-1"
  ],
  "trackingStoreName": "watched-items-fr"
}

Why this is better than "sold items" mode

Classic SOLD_ITEMS mode only returns listings that Vinted explicitly marks as sold. When Vinted hides sold search results, the honest output is an empty dataset.

That is useful if you need strict confirmed sold data. It is not enough if you want market intelligence.

For market research, a snapshot-based tracker is more practical:

It works even when sold listings are hidden
It catches demand by query, brand, size, and country
It separates temporary disappearance from repeated disappearance
It creates a time series you can export to CSV, Excel, or BI tools

The output is not magic. It is a confidence signal. But for resellers, buyers, and analysts, confidence over time is usually more valuable than a fake "sold" flag.

Where this fits in the actor

Vinted Smart Scraper still supports regular catalog search, item detail extraction, seller profiles, price tracking, trending items, and cross-country price comparison across 26 Vinted markets.

Current public stats as of May 30, 2026:

106,976 total runs
425 users
99 users in the last 30 days
5.0 rating from 4 reviews

Current pricing is pay-per-event: $1.50 to $2.00 per 1,000 dataset items depending on Apify plan, plus a small actor-start event.

If you need Vinted demand data, start here:

Run Vinted Smart Scraper on Apify

Use SOLD_ITEMS only when you need explicitly exposed sold listings. Use SELL_THROUGH_TRACKER when you need the demand signal Vinted no longer makes easy to scrape directly.

I built an Apify actor that turns vet clinic lists into buyer-fit M&A targets

KazKN — Sat, 30 May 2026 19:19:20 +0000

A generic clinic list is not a sourcing workflow.

For veterinary M&A, the expensive part starts after the scrape: removing chains, spotting likely independent practices, deciding which targets deserve review now, and mapping each record to a buyer thesis.

I built Vet Practice M&A Targets, an Apify actor that turns public veterinary practice records into a ranked, buyer-fit acquisition queue.

Watch the tutorial video

Run Vet Practice M&A Targets on Apify

Concept visual: the useful output is not a directory. It is a review queue.

The problem with generic clinic lists

If you source in a niche vertical, generic business databases create a strange kind of waste.

They can give you records, but they usually do not understand the vertical-specific exclusion rules.

In veterinary M&A, that matters because a clinic name can look like an independent target while actually being part of a known platform, brand family, specialty network, or corporate buyer ecosystem.

So a human still has to do the same cleanup loop:

remove obvious corporate or chain-owned records;
dedupe locations and names;
inspect websites and market signals;
decide whether the target is review-worthy now;
guess which acquirer profile might fit;
export the result into a CRM, spreadsheet, or internal review process.

That is not only a data problem.

It is a workflow problem.

What the actor does

The actor is built around the acquisition review workflow:

Select states.
Pull public veterinary practice records.
Exclude obvious chain-owned or corporate-owned records.
Score remaining practices on M&A readiness.
Map each target to a likely buyer profile.
Export structured records for review, outreach, or downstream automation.

The default tutorial run uses a focused five-state sample: Florida, Texas, California, New York, and Illinois.

That matters because you should not pay for a broad national run before checking whether the output matches your review process. A small sample is enough to inspect the shape of the data, the false positives, the scoring logic, and the export fields.

The actor is designed to move from extraction to decision support, not stop at scraping.

Output fields that matter

Core output fields include:

practice name and location;
website and phone when available;
chain status;
M&A readiness score;
buyer match;
buyer-match confidence;
buyer-match reasoning;
optional Google Maps and Yelp context;
export-ready structured fields.

The scoring is not meant to be a valuation model.

It is a prioritization layer. It answers a narrower question: should this record be reviewed now, watched later, or ignored?

Why buyer-fit matters

Not every good veterinary practice fits the same acquirer.

A suburban general practice may look closer to a VetCor-style target. A specialty or emergency signal may point toward a Mars / VCA / BluePearl / Banfield-style profile. A dense metro clinic may map differently from a rural or mid-tier market clinic. A regional rollup thesis may care more about geography and consolidation density than brand prestige.

The useful output is not only a score.

The useful output is a score plus reasoning, so a reviewer can understand why a target landed in a given bucket.

That makes the model auditable. A human can disagree with it, but they can see what triggered the recommendation.

Google Maps and Yelp enrichment

The actor can add public review and location context when enrichment is enabled.

I treat Google Maps and Yelp as enrichment, not as the core product. The core product is the structured sourcing list: independent practice detection, readiness scoring, buyer-fit mapping, and exportable records.

For Yelp, the clean path is the official Yelp Fusion API when a key is provided. That is more reliable than brittle browser scraping and avoids making the product depend on anti-bot behavior.

Integration options

Once a run finishes, you can use the output in several ways:

download CSV or Excel for analyst review;
pull JSON from the Apify dataset API;
call the actor from the Apify CLI;
schedule recurring runs;
expose the output through OpenAPI or MCP-style workflows;
push records into a CRM or internal diligence process.

The point is not to replace judgment.

The point is to remove list cleaning from the critical path so judgment starts earlier.

A first test run

For a first pass, I would run:

states: FL, TX, CA, NY, IL;
max targets per state: 30;
minimum readiness score: 7+ if you want a tighter review list;
enrichment: off for a fast first pass, on when you want public review context.

Then inspect:

whether the buyer-fit reasoning makes sense;
whether the target names look independent;
whether the exported fields match your CRM or review workflow;
whether one or two states deserve a deeper run.

That is a better validation loop than starting with a giant spreadsheet and hoping the signal appears later.

Links

Disclosure: the Apify links above include my referral code.

If you work on acquisition sourcing, vertical data products, or Apify actors, I would be interested in feedback on the scoring model and output fields.