For resellers and e-commerce analysts, eBay has one thing almost no other marketplace gives you publicly: sold listings. Most sites show you asking prices. eBay shows you what things actually sold for, at what date, in what condition, from which seller. That’s not a pricing signal, it’s transaction data, and it’s why eBay functions as a public price oracle for everything from sneakers to industrial parts.
Collecting it reliably is the hard part. eBay runs separate regional marketplaces with different prices and demand, defends against automated access, and personalizes results to the visitor. Pull that data from a single office IP and you get one country’s view, riddled with gaps. This guide covers what’s worth collecting, when to use the official API instead, and how to gather the rest accurately with residential proxies.
What’s actually worth collecting
An eBay listing page is dense, but analysts really care about a specific subset:
Listing-level
- Price and format — the price, and crucially whether it’s auction or Buy It Now. Mixing the two corrupts any average you compute.
- Condition — new, used, refurbished, for parts. On eBay, condition drives price variance more than almost anything else.
- Shipping and location — cost and item location, which change the true landed price.
- Item specifics — brand, model, size, and the structured attributes that make listings comparable.
Sold / completed listings (the valuable part)
- Realized price and sale date — what buyers actually paid, and when.
- Sell-through — how many of the listings for an item actually sold versus expired unsold. This is the number that separates “worth sourcing” from “sits forever.”
Seller-level
- Feedback score and rating, store name, and whether it’s a business seller.
- Assortment and pricing behavior — what a competing seller lists, at what prices, and how fast it moves.
That third category is what turns collection into competitive intelligence: not just what a product sells for, but which sellers are winning at it.
Start with the official API where it fits
Worth saying plainly, because it will save you effort: eBay has an official API, and where it covers your need it’s the right first stop. It’s stable, structured, doesn’t break when markup changes, and it’s explicitly sanctioned. If you need standard listing data and your volumes and regions fit within its terms and limits, use it.
Proxies come in for the cases the API doesn’t serve well: public data outside the API’s scope, coverage across regional marketplaces at analyst-level breadth, or seeing the marketplace exactly as a local buyer sees it. The honest framing is that these are complements, not substitutes, and starting with the API where it fits is simply better engineering.
Why the rest is a proxy problem
Three properties of eBay make broad public collection an access problem.
eBay is split by marketplace, and geo-personalized. ebay.com, ebay.co.uk, ebay.de, ebay.com.au are different marketplaces with different inventory, prices, demand, and sell-through. Even within one, results are personalized to the visitor’s location, shipping options and item availability change. For a reseller doing cross-border arbitrage, this is the analysis: what a thing fetches in the UK versus Germany. Fetching ebay.de from a US IP gives you neither view accurately, so you need to be in the market you’re measuring (country and city targeting).
eBay defends against automated access. Like any large marketplace, it runs anti-bot systems. Data-center IPs get flagged, throttled, or served interstitials, so you record the bot version instead of the buyer’s page (why scrapers get blocked). Residential IPs carry real-user trust and see the real listing.
Coverage is broad and repeated. A category sweep across several marketplaces, refreshed daily to keep sell-through current, is a lot of requests. From a handful of IPs you trip rate limits and end up with a partial sample, which is fatal here: a sell-through rate computed from a sample biased by blocks is worse than no number at all.
Routing to the right marketplace
On the Shifter gateway, you pick a country by encoding it in the proxy username, one endpoint, no IP lists. Match the proxy country to the marketplace domain:
# ebay.com as a US buyercurl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 \ "https://www.ebay.com/itm/123456789012"
# ebay.co.uk as a UK buyercurl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 \ "https://www.ebay.co.uk/itm/123456789012"Note the country code for the UK is gb, not uk, a small thing that silently produces wrong-market data if you get it wrong.
Collecting in code
Most eBay listing data is in the initial HTML, so a plain HTTP client is faster and far cheaper than driving a browser (see residential proxies with Python for the full client setup):
import os, requestsfrom bs4 import BeautifulSoup
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]
def proxy(country="us"): url = f"http://{USER}-country-{country}:{PASS}@p.shifter.io:443" return {"http": url, "https": url}
MARKETS = {"us": "ebay.com", "gb": "ebay.co.uk", "de": "ebay.de"}
def fetch_listing(item_id, country="us"): domain = MARKETS[country] url = f"https://www.{domain}/itm/{item_id}" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept-Language": "en-GB,en;q=0.9" if country == "gb" else "en-US,en;q=0.9", "Accept-Encoding": "gzip, br", } r = requests.get(url, headers=headers, proxies=proxy(country), timeout=30) r.raise_for_status() soup = BeautifulSoup(r.text, "html.parser") return { "item_id": item_id, "market": country, "title": (t := soup.select_one("h1")) and t.get_text(strip=True), "price": (p := soup.select_one(".x-price-primary")) and p.get_text(strip=True), # Condition, shipping and item specifics live in their own blocks; # treat every selector as optional and validate what you extract. }Two practical notes. Set Accept-Language to match the marketplace you’re targeting, a UK IP sending en-US is an inconsistency you don’t need. And treat every selector as optional: eBay’s markup varies by category and listing type, so parse defensively and validate rather than assuming a field exists.
Rotate per request for broad category sweeps; hold a sticky session when paginating through a single seller’s inventory so the sequence looks like one shopper. Because IP quality decides how often you see the real page, IP reputation is worth understanding, and consistent (not occasional) blocks point to quality or behavior (how to avoid getting blocked).
Turning listings into analysis
Collection is the input; the analysis is where resellers actually make money. A few things that matter when you model this data:
Separate sold from active. Active listings are asking prices, which is aspiration. Sold listings are transactions. Never average them together, and never quote an “eBay price” without saying which one you mean.
Segment by condition and format. A used item’s realized price and a new one’s are different markets. Auction closes and Buy It Now sales behave differently too. Averaging across those segments produces a number that describes nothing.
Compute sell-through, not just price. Sold divided by total listed over a window tells you liquidity. A high price with 10% sell-through is a worse sourcing target than a lower price that clears reliably.
Compare across marketplaces deliberately. Cross-border price gaps are the reseller’s edge, but only if each market’s figure was actually collected from that market, which is exactly why the geo routing above matters.
For structuring the output into a research-ready dataset, how to build a dataset with web scraping covers the mechanics, and the same discipline underpins price monitoring and digital shelf analytics.
Using it responsibly
Collect public listing data only, titles, prices, conditions, shipping, and public seller metrics any buyer can see. Personal data is off-limits: buyer identities, private messages, and personal details attached to accounts are not fair game, and feedback comments should be handled carefully since they can contain personal information.
Beyond that: honor eBay’s terms and rate limits, don’t degrade the site, and prefer the official API where it covers your use case. eBay’s terms restrict automated access, so keep collection to public data, stay at a reasonable pace, and get legal advice for anything uncertain (is web scraping legal). A proxy changes which IP a request comes from, not whether you should be making it; our acceptable use policy is the source of truth for what’s allowed on Shifter.
FAQ
Why do I need proxies for eBay data? Because eBay runs separate regional marketplaces with different prices and demand, personalizes results by location, and defends against automated access. From one IP you see one market, partially. Residential proxies let you collect each marketplace as a real local buyer.
Should I use the eBay API instead? Where it covers your need, yes, it’s stable, structured, and sanctioned. Proxies are for public data outside its scope or for breadth across regional marketplaces. Start with the API and use collection for the rest.
Can I collect sold and completed listings? Sold listings are shown publicly and are the most valuable input for resellers, since they’re realized prices rather than asking prices. Collect them as public data, keep sold and active separate in your analysis, and respect eBay’s terms and rate limits.
Why does the UK need country code gb?
Because the gateway uses ISO country codes, where the United Kingdom is gb. Using uk silently fails to target correctly, which means you’d be collecting ebay.co.uk from the wrong market and not realize it.
Residential or datacenter proxies for eBay? Residential. Marketplaces detect and treat data-center IPs differently, so you’d get throttled or served a degraded page. Residential IPs see the real, geo-accurate listing a genuine buyer would.
The bottom line
eBay’s public sold-listing data is unusually valuable because it’s transactional, not aspirational, and it’s the backbone of sourcing, pricing, and sell-through analysis for resellers. The catch is that it’s split across regional marketplaces, personalized by location, and defended, so the accuracy of your analysis depends entirely on collecting each market as a real buyer in that market. Use the official API where it fits, route the rest through residential IPs matched to the marketplace, parse defensively, and keep sold separate from active in the model.
Do that and you get numbers you can source and price against instead of a blended average that describes nothing. A quality residential proxy network is what keeps that collection geo-accurate and complete, and the pricing page has the per-GB plans to trial it against the categories and marketplaces you actually trade in.