Proxies for Fashion Resale Market Data

The platforms change their defences often, so treat that table as a starting point and confirm on a small trial against your own target list before sizing a plan.

The buyer decides the data shape, and the data shape decides the infrastructure. Five groups account for most demand.

Brands track what their products resell for, how quickly they sell and in which condition. The questions are strategic: is a line holding value, are counterfeits showing up, is a region flooded with unsold stock. They need breadth and trend lines, not second-by-second freshness.

Resellers and sourcing businesses need the sell price net of fees for specific items, fast. Freshness matters because a mispriced listing disappears within hours. Our page on proxies for retail arbitrage covers the buy side of that trade.

Pricing tools and marketplace apps give sellers suggested prices, so they need comparable sold data at the level of brand, model, size and condition, refreshed daily.

Investors and analysts follow category-level indicators: average resale-to-retail ratio for a brand, listing growth, sell-through. They want clean, consistent history more than coverage of every listing.

Authentication and anti-counterfeit services look for suspicious listings: prices far below market, reused photos, sellers with patterns. They need images, which changes the bandwidth picture completely.

Be honest about which group you are. A brand-health dashboard refreshed weekly and a reseller alert system refreshed every ten minutes can differ in cost by two orders of magnitude.

Most projects underinvest in the sold layer and overinvest in active listings. Asking prices are easy to collect in bulk and systematically higher than what items sell for, particularly on peer-to-peer apps where sellers start high and negotiate or reduce. An index built only on asks describes seller optimism.

Group marketplaces by how they behave toward automated traffic, not by what they sell. Then buy access per group.

Profile 1: API-first. eBay is the clearest example. It publishes developer APIs for search and item data, so most collection should not touch its web pages at all. Proxies play a supporting role at most.

Profile 2: open catalogues with rate limits. Peer-to-peer fashion apps and several consignment sites serve public search and listing pages to anonymous visitors, then throttle by IP when request rates climb. Many work from datacenter IPs at sensible rates. The challenge is volume: millions of listings, image-heavy pages and country-specific storefronts. Rotation across a large pool and unmetered bandwidth matter more here than IP type.

Profile 3: defended exchanges. Sneaker and streetwear exchanges price items like a stock market and protect that data with commercial bot management. Plain datacenter requests tend to fail on key pages, and sessions often need a real browser fingerprint. Scope is smaller (you track SKUs and sizes, not millions of listings), so cost per successful request matters more than raw throughput.

SparkProxy fits Profile 2 directly: rotating datacenter proxies from a pool of 1M+ IPs across 80+ countries, on flat plans with unlimited bandwidth. It does not sell residential proxies. For Profile 3, the practical options are its managed Scraping API or a residential provider, and you should test the success rate on your own SKU list before committing. Our breakdown of residential vs datacenter proxies explains why the split exists.

Every request you can move to an official channel is a request you do not need to route, retry or defend.

eBay's developer program offers a Browse API for active listings and item details, and a Marketplace Insights API for sold-item data that requires approval for access. If eBay is a major source for you, apply for the access you need before building anything that loads eBay's search pages. The approval process takes time, so start it in the first week, not after the scraper is written.

Some exchanges and resale platforms offer APIs to sellers for managing their own inventory. Those are useful when your business is a seller on the platform, but they are rarely designed for market-wide data. Read the terms: a seller API used for market analytics can cost you the seller account.

Where no API exists, collect from public pages at rates the site can clearly absorb. Our guide to ethical scraping and rate limiting sets out a defensible baseline.

Fashion resale is less global than it looks. Many platforms run country-specific storefronts with their own currency, fees, shipping rules and, crucially, their own supply.

Vinted operates separate country domains across Europe, and the same brand and size can carry a different typical price in France than in the UK. Luxury consignment sites show prices in local currency, and stock visible in one market may not be purchasable in another. Sneaker exchanges show region-specific pricing and fees in many markets.

For analytics this has three consequences:

1. Collect each market from its own storefront, and where a platform geolocates visitors, from an exit IP in that country. A French storefront loaded from a US IP can redirect, change currency, or hide shipping options.
2. Store prices in original currency with the capture date, and convert in the analysis layer with a dated exchange rate. Converting at capture time bakes in a rate you cannot audit.
3. Normalise fees and shipping separately. A lower list price in one country can be the more expensive item once buyer fees and cross-border shipping are added.

The regional spread is often the most valuable output of a resale dataset, because it is where resellers and brands find mispriced supply. It is also the part single-country collection misses entirely.

A caution on plan choice: SparkProxy's proxy plans provide USA and worldwide rotating pools, and the Scraping API accepts a country_code for exact country targeting. If your collection depends on a specific European storefront seeing a local visitor, use the API parameter or verify each exit's location, rather than assuming a worldwide pool lands where you need it.

When a platform does not publish sold prices, teams infer sales from listings that disappear. That works less well than it sounds.

A listing can vanish because it sold, because the seller deleted it, because it was reported and removed, because the seller relisted it with a new ID to bump it in search, or because it was reserved in a private deal. Treating every disappearance as a sale inflates sell-through and pulls the inferred price toward optimistic asks.

Practical corrections:

• Prefer platforms with explicit sold states for your price index, and use disappearance-based estimates only as a supplementary signal.
• Revisit active listings more often than their typical lifetime, or you will miss the final reduced price before the sale. For fast-moving categories that can mean daily or more. The Vinted post covers measuring sell-through rate on a single platform in detail.
• Detect relists by matching new listings against recently vanished ones on seller, title, brand, size and image similarity. A relist is not a sale.
• Publish your method. Any sold-price figure derived from disappearance should say so, because consumers of the data will otherwise treat it as transaction data.

Revisit frequency is also the biggest single cost lever in this whole project, which is why sizing comes after this section and not before.

Resellers commonly list the same item on several platforms at once and delete it everywhere when it sells. Count listings naively across marketplaces and supply looks two or three times larger than it is.

Deduplicate before computing supply. Title and attribute matching catches some duplicates, but sellers rewrite titles per platform. Image matching catches more, because the same photos are reused. Perceptual hashing works on resized thumbnails, so you rarely need full-resolution downloads:

# pip install imagehash pillow requests
import io, requests, imagehash
from PIL import Image

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11000"
proxies = {"http": PROXY, "https": PROXY}

def thumb_hash(url):
    r = requests.get(url, proxies=proxies, timeout=20)
    r.raise_for_status()
    return imagehash.phash(Image.open(io.BytesIO(r.content)))

def likely_same_item(listing_a, listing_b, max_distance=6):
    if listing_a["brand"] != listing_b["brand"] or listing_a["size"] != listing_b["size"]:
        return False
    return thumb_hash(listing_a["thumb_url"]) - thumb_hash(listing_b["thumb_url"]) <= max_distance

Tune max_distance on a hand-labelled sample from your own data. Lower values miss duplicates with different crops, higher values merge different items that share a studio background, which is common for consignment stock photographed on the same set.

There are two collection shapes, and most teams need a mix.

A SKU watchlist tracks named products (a sneaker model in each size, a handbag reference) on a few platforms, frequently. Request counts are predictable and pages are specific.

A catalogue sweep walks categories or searches to measure the whole market: supply, price distribution, new listings. Request counts are large, pages carry many thumbnails, and freshness requirements are looser.

Two illustrative sizings, built on assumptions we chose to be plausible rather than measurements:

The watchlist is small in requests but expensive per request, because defended exchanges push you toward rendering or premium routes. The sweep is large but cheap per request, and it punishes any plan that meters bandwidth: listing grids are thumbnail-heavy, and a metered plan charges for every image your parser never looks at. Blocking images and fonts where you do not need them cuts transfer sharply, as our guide to reducing proxy bandwidth costs explains.

Revisits dominate both. Doubling check frequency doubles the bill on every plan type except flat, concurrency-priced proxies, where it only matters if you need more parallel threads to finish on time. For change detection that avoids refetching unchanged pages, see incremental web scraping.

For most resale data teams the answer is both, split by access profile.

Catalogue sweeps on open marketplaces: a flat proxy plan. SparkProxy's plans are priced by concurrent threads with unlimited bandwidth: Starter $75/mo for 100 threads, Core $140 for 250, Boost $240 for 500, Plus $440 for 1,000. Connect to gateway.sparkproxy.io on port 11000 for per-request rotation, 11002 for sticky sessions when a platform ties search pagination to a session, or 13000 for SOCKS5. A sweep of the size in the table above sits comfortably on Starter or Core, depending on how fast each pass must finish.

SKU watchlists on defended exchanges: a managed API. The Scraping API handles rendering and anti-bot behaviour per request. Credit costs from the documentation: 1 credit for a plain fetch, 5 with JavaScript rendering, and 5 more with country_code. As an illustration, the 540,000-request watchlist above at 5 credits is 2,700,000 credits a month, inside the Pro tier ($249 for 3,000,000). If most pages need rendering plus country targeting, 10 credits each, the same volume needs 5.4 million credits, which moves to the Scale tier ($599 for 8,000,000). If the exchange also needs premium routing, the credit cost per request rises again, so run your SKU list through the 1,000 free credits and read the X-Credits-Used header before estimating.

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://www.sparkproxy.io/pricing" \
  --data-urlencode "render_js=true" \
  --data-urlencode "block_resources=true" \
  --data-urlencode "format=json" \
  -D - -o page.json | grep -i "x-credits-used"

Swap in a product page from your watchlist, then multiply the credits used by your monthly request count. That one number replaces any estimate on this page.

Resale marketplaces are full of personal data: usernames, profile photos, locations, sometimes real names. Market analytics almost never needs any of it.

Design the schema without seller identity from the start. If relist detection needs a seller key, store a salted hash rather than the username, and drop it after the matching window. Avoid anything behind a login. Read each platform's terms, and treat automated access restrictions as a business risk to weigh, not a technicality. The Vinted tutorial's section on the privacy boundary is a good model for other platforms too, and our overview of whether proxies are legal for business use covers the wider picture. None of this is legal advice.