Vestiaire Collective Scraper: Built From 11,263 User Reviews

Most Vestiaire Collective scrapers start from the website.

I started from the users.

Before building a Vestiaire Collective scraper, I analyzed 11,263 public App Store and Google Play reviews, plus a Trustpilot sample, to understand what people actually worry about when they buy or sell on the platform.

The conclusion was clear: users are not only talking about fashion.

They are talking about risk.

They use words like seller, buyer, sold, item, fake, authentication, fees, commission, refund, money back, customer service, account, doesn't work, and waste of time.

That changed the product.

Instead of building a basic product-card scraper, I built the Vestiaire Collective Smart Scraper on Apify around the workflows that reduce uncertainty: sold items, seller countries, item condition, price tracking, product details, seller summaries, and duplicate/suspicious listing signals.

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

Reviews are product research

A normal ecommerce scraper usually collects:

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

That is not enough for a resale marketplace.

On Vestiaire Collective, the real questions are different:

• Is the item still available or already sold?
• Where is the seller located?
• Is the condition clear?
• Is this price low compared with other markets?
• Has the listing price changed?
• Is the same listing appearing across several market pages?
• Are several listings suspiciously similar?
• Does the product page expose richer details than the search result?

Those questions came directly from the language users use in reviews.

When people complain about money, refund, fees, or commission, they are asking for better price and transaction context.

When they complain about fake, authentication, photos, description, or quality control, they are asking for better product-detail and risk context.

When they mention seller, buyer, sold, or selling, they are asking for marketplace intelligence, not just product extraction.

That is the core idea behind the Actor.

What the review data changed in the Actor

The review analysis did not become the dataset.

It became the product brief.

Here is how the main user anxieties became actual scraper features.

User language found in reviews	Product decision in the scraper
seller, buyer, selling, sold	Extract seller metadata, seller country, sold records, and seller summaries
money, refund, fees, commission	Track public prices, price history, sold prices, and market comparisons
fake, authentication, photos, description	Add product detail enrichment and conservative duplicate/risk signals
item, condition, not as described	Expose item condition, condition source, title/model filters, and original URLs
account, doesn't work, waste of time	Keep the input simple, output readable, and diagnostics explicit
easy to use, great app, highly recommend	Make the Actor usable from the Apify UI without writing code

This is why the Actor does more than scrape a search page.

The most important field is not always price

Price matters, but price alone is misleading.

A Chanel Classic Flap at a low price is not automatically a deal. You also need to know:

• the condition;
• the seller country;
• the searched market country;
• the listing status;
• the public product URL;
• whether the same item appears in several markets;
• whether the item later disappears;
• whether similar records are clustered together.

That is why the Actor separates country and sellerCountry.

country is the Vestiaire market page searched.

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

For sourcing, sellerCountry is often more important. If you only want French sellers, you can search all markets but filter with:

{
  "sellerCountries": ["FR"]
}

If you want market comparison, you can search specific locales:

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

The Actor supports both because the review data showed that users think in marketplace risk, not in clean ecommerce categories.

Sold items matter because active listings lie by omission

If you only collect active listings, you only see supply.

You miss demand.

Review language around sold, sale, buyer, purchase, and money shows that users care about what actually moves, not just what is listed.

That is why the Vestiaire Collective Smart Scraper can collect sold-item records from public sold-search filters and sold-item pages when available.

A sold-item workflow can be as simple as:

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

This lets you compare active supply with sold signals.

For resale research, that is more useful than another table of product cards.

Condition and precision filters reduce noise

One of the strongest review themes was item conformity.

Users mention item, items, description, photos, condition, quality control, fake, and not as described.

A scraper cannot decide whether an item is authentic. It should not pretend to.

But it can reduce noise and expose the fields that help manual review.

For example, the Actor supports Vestiaire condition filters:

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

Where:

• 3 = Very good condition
• 4 = Good condition

It also supports a precision filter:

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

That matters because a broad query like chanel classic flap can return nearby but irrelevant results such as other flap bags, shopping totes, or different Chanel models.

The goal is not to make the scraper "smart" in a vague way.

The goal is to let the user encode the exact model they care about.

Duplicate and suspicious signals are review signals, not accusations

Reviewers use intense words around risk: fake, scam, avoid, fraud, stolen, worst customer service.

That does not mean a scraper should label sellers as fraudulent.

It means the scraper should surface records that deserve manual review.

The Actor includes conservative duplicate/risk signal rows based on public-record similarity. It can flag clusters where listings look unusually similar across title, brand, category, image URLs, price band, or seller-related fields.

The output is intentionally framed as a signal:

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

It is not proof.

It is a shortlist for human inspection.

That distinction is important for a luxury resale workflow.

Price tracking turns one-off scraping into monitoring

A one-time scrape tells you what existed at one moment.

A scheduled Actor run tells you what changed.

Because review language includes price, fees, commission, money, refund, and paid, pricing context matters. But the useful signal is often not the current price. It is the change.

The Actor can keep durable tracking state between runs using a named key-value store.

That allows repeated runs to build public price history:

{
  "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"
}

It can also emit likely-sold tracking records when a previously observed listing disappears for a configured number of runs.

That is useful for:

• price-drop monitoring;
• deal alerts;
• sell-through research;
• recurring watchlists;
• market comparison across countries.

Example: find underpriced items without drowning in noise

Here is a practical deal-finding input:

{
  "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 does four things:

1. Searches several Vestiaire market locales.
2. Keeps only very good / good condition items.
3. Requires the model phrase classic flap.
4. Adds detail and seller summary rows for review.

The output is easier to inspect because each row includes fields such as:

{
  "recordType": "listing",
  "displayStatus": "Available",
  "isSold": false,
  "listingId": "67486244",
  "brand": "Chanel",
  "title": "Sac a main en cuir Classic CC Shopping",
  "price": 1000,
  "currency": "EUR",
  "priceText": "1000 EUR",
  "country": "FR",
  "sellerCountry": "FR",
  "condition": "Very good condition",
  "conditionSource": "vestiaire",
  "url": "https://fr.vestiairecollective.com/..."
}

This is the difference between scraping and workflow design.

Example: search every market but keep only French sellers

The review data showed that seller and buyer trust are central.

So the Actor lets users search broadly but filter sellers narrowly.

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

This is useful when you do not know which market locale will expose the listing, but you care about where the seller is located.

That distinction exists because real users do not think like a website navigation menu. They think in constraints:

• "I only want sellers from this country."
• "I only want this condition."
• "I only want this exact model."
• "I want sold signals, not only active listings."
• "I want to know if this seller keeps appearing."

The Actor input is designed around those constraints.

Built for Apify workflows

You can run the Vestiaire Collective Smart Scraper directly from Apify.

It supports:

• no-code runs from the Apify UI;
• scheduled monitoring;
• JSON, CSV, Excel, and API export;
• Apify Proxy configuration;
• durable tracking state between runs;
• dataset views for listings, sold items, product details, seller summaries, risk signals, and diagnostics.

The Actor searches all 70 supported Vestiaire market countries by default when countries is left empty or set to ALL, but users can restrict countries when they want smaller runs.

The goal is not to force one workflow.

The goal is to give sourcing, resale, pricing, and market-research users enough controls to match their own risk model.

What this scraper does not claim

This 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.

That is the right level of responsibility for this kind of tool.

The review data showed that users want more certainty, but a scraper should not invent certainty. It should expose signals clearly.

Final thought

The best scrapers are not built around selectors.

They are built around decisions.

For Vestiaire Collective, the decision is rarely "what is the title and price?"

The real decision is:

• Is this listing worth trusting?
• Is this price actually attractive?
• Is this seller relevant to my market?
• Has this item sold before?
• Is the same product appearing repeatedly?
• Is the condition good enough?
• Should I inspect this manually before buying or reselling?

That is why I built the Vestiaire Collective Smart Scraper around sold items, seller intelligence, price tracking, conditions, product details, and duplicate signals.

Because the users already told us what mattered.

They just said it in reviews.