DEV Community

Cover image for I Built an Apify Actor to Compare Luxury Handbag Resale Prices Across 4 Marketplaces
KazKN
KazKN

Posted on

I Built an Apify Actor to Compare Luxury Handbag Resale Prices Across 4 Marketplaces

#apify #webscraping #automation #javascript

I built an Apify Actor that compares public resale listings for Hermes Birkin, Hermes Kelly, and Chanel Classic Flap bags across four marketplaces:

  • Vestiaire Collective
  • Rebag
  • Fashionphile
  • 1stDibs

Actor:

https://apify.com/kazkn/hermes-birkin-kelly-arbitrage

Short demo:

https://youtube.com/shorts/h0JEDFitqao?feature=share

The goal is not to build an auto-buy bot.

The goal is to turn messy marketplace pages into a dataset that can be reviewed before any human decision.

The Problem

Luxury resale comparison is messy because public listings are inconsistent.

One marketplace exposes condition clearly. Another hides useful data inside the detail page. One title includes hardware. Another only says "leather". One listing is priced low because condition is weaker. Another is priced high because the seller is testing the market.

Manual spreadsheet comparison breaks quickly.

The Actor turns that into a repeatable workflow:

  1. Collect public listings.
  2. Normalize listing fields.
  3. Group comparable bags.
  4. Calculate gross spread.
  5. Estimate net ROI after cost assumptions.
  6. Output review candidates and warnings.

Input Design

The input is designed for non-technical users first.

Main sections:

  • Scan scope
  • Strict target
  • Scan limits
  • Deal thresholds
  • Cost assumptions
  • Platform fee assumptions
  • Output and proxy settings

Users can run a broad scan:

{
  "platforms": ["vestiaire", "rebag", "fashionphile", "1stdibs"],
  "models": ["birkin", "kelly", "classic_flap"],
  "targetingMode": "broad_scan",
  "maxListingsPerMarketplace": 60,
  "maxPagesPerMarketplace": 1
}
Enter fullscreen mode Exit fullscreen mode

Or they can run a strict watchlist:

{
  "targetingMode": "strict_target",
  "targetModel": "birkin",
  "targetSize": "30",
  "targetColor": "black",
  "targetMaterial": "togo",
  "targetHardware": "gold",
  "minimumCondition": "very_good"
}
Enter fullscreen mode Exit fullscreen mode

The watchlist matters because many users already know the exact bag they want. They do not need every listing. They need to know whether a narrow target appears across platforms.

Normalization

The Actor normalizes fields like:

  • brand
  • model
  • size
  • colorBucket
  • materialBucket
  • hardwareBucket
  • conditionBucket
  • price
  • currency
  • platform
  • listingUrl

The hard part is not scraping the title.

The hard part is turning different marketplace language into comparable buckets without pretending incomplete data is perfect.

That is why the output includes warnings. A relaxed match is useful, but it is not the same as a strict match.

Spread And ROI

There are two gates.

Gross spread:

grossSpreadPercent = (referenceSellPrice - buyCandidatePrice) / buyCandidatePrice
Enter fullscreen mode Exit fullscreen mode

Estimated net ROI:

estimatedNetRoiPercent = estimatedNetProfit / landedBuyPrice
Enter fullscreen mode Exit fullscreen mode

The landed buy price can include:

  • shipping or insurance estimate
  • authentication or repair buffer
  • FX and tax buffer

The sell-side value deducts platform fee assumptions.

This is intentionally conservative. A listing can have a large headline spread and still become unattractive once costs are added.

Output Records

The dataset includes different record types:

  • normalized_listing
  • spread_candidate
  • watchlist_candidate
  • arbitrage_opportunity
  • unmatched_listing
  • platform_error
  • run_summary

I keep these separate because a scraper should not overstate confidence.

For example:

  • A spread_candidate means "review this".
  • An arbitrage_opportunity means stricter filters passed.
  • A platform_error means a marketplace failed and should not be silently ignored.
  • A run_summary helps you understand coverage, failures, and counts.

Why Apify

Apify is useful here because the workflow benefits from:

  • scheduled runs
  • proxy support
  • structured input schema
  • dataset output
  • API access
  • monetization support
  • readable actor logs

This kind of workflow is not a one-off script. Users want to run it daily, change scan scope, export results, and plug the dataset into another process.

Limitations

This Actor does not:

  • authenticate bags
  • guarantee resale profit
  • scrape private sales
  • provide investment advice
  • prove sold prices
  • bypass marketplace rules

It compares public active listings and makes the review process cleaner.

That boundary is important.

What I Would Improve Next

Useful next steps:

  • deeper detail page enrichment
  • better sold-comps integration where legally available
  • more marketplace-specific fee models
  • alerting for saved watchlists
  • CSV templates for reseller workflows
  • historical price tracking per model/size/material group

Try It

Actor:

https://apify.com/kazkn/hermes-birkin-kelly-arbitrage

Short demo:

https://youtube.com/shorts/h0JEDFitqao?feature=share

If you build Apify Actors, the main takeaway is not the luxury niche. The reusable pattern is:

public marketplace data -> normalized records -> comparable groups -> warnings -> review queue.

Top comments (0)