DEV Community: Sam Smith

I logged every status code scraping eBay sold listings. The block is not where you think

Sam Smith — Sat, 17 Oct 2026 18:29:56 +0000

Every tutorial for this is the same twelve lines. I ran them today, logged every status code, and the interesting part is not that it failed. It is where it failed, which turns out to be a different place than the tutorials assume.

All numbers below are from 17 October 2026, from one residential address, in the order shown.

Attempt 1: the twelve lines

import requests

url = "https://www.ebay.com/sch/i.html"
params = {"_nkw": "incredible hulk 181", "LH_Sold": 1, "LH_Complete": 1}
headers = {"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
                         "AppleWebKit/537.36 (KHTML, like Gecko) "
                         "Chrome/129.0.0.0 Safari/537.36"}

r = requests.get(url, params=params, headers=headers, timeout=30)
print(r.status_code, len(r.content))   # 403 1832

403, 1,832 bytes. Not a captcha, not a login redirect. A page titled Error Page | eBay carrying <meta name="robots" content="noindex,nofollow">.

The useful control: the same request with the sold flags removed, against the ordinary active search, also returned 403, at 1,831 bytes.

So the first block has nothing to do with sold data. It is the request not looking like a browser.

Attempt 2: look like a browser

Copy a real request's headers. accept, accept-language, the sec-ch-ua client hints, the sec-fetch-* set, upgrade-insecure-requests. This is where it gets interesting, because the same headers produced different outcomes for the two URLs.

Request	Result
User agent only, active search	403, 1,831 bytes
User agent only, sold search	403, 1,832 bytes
Full header set, active search	200, 198,706 bytes, 67 listings
Full header set, sold search	302, empty body

Identical headers. The active search handed over a real page with 67 listing ids in it. The sold search did not.

That is the actual shape of the problem. Active listings are public and indexable. Completed sales are the dataset eBay sells research subscriptions against.

Attempt 3: it stops working at all

Retrying the sold URL a minute later, following redirects this time, returned 403 rather than the 302.

Then I ran ten more trials, alternating active and sold, ten seconds apart. 403 on all ten, including the active search that had worked minutes earlier.

Total requests before the address was finished: about fifteen.

So there are two findings here, not one:

Sold search is gated harder than active search.
The dominant effect over any real workload is address reputation, not headers.

Point 2 is the one that kills projects. Your scraper works on your laptop for an afternoon and dies the moment it does anything useful.

The selector in every tutorial is also wrong

Worth knowing if you do get a page back. Essentially every tutorial and Stack Overflow answer parses .s-item__price.

In the 200 response above, that selector matched zero elements. The prices were in .s-card__price, 70 of them.

eBay reworked the search markup. The tutorials did not. If your scraper quietly returns empty lists, check the class names before you check your parsing.

Why there is no API to fall back to

The usual next question is why not use eBay's own API. The short version:

findCompletedItems, the Finding API call that returned sold listings, is retired.
The Browse API is open to everyone and returns active listings only. There is no sold filter, because sold items are not in the index it reads.
The Marketplace Insights API does carry sold data. It is a limited release restricted to approved partners, and it caps at 90 days.
Terapeak, now Product Research in Seller Hub, has three years of it and no API, no export, and requires a signed in seller session.

That is the whole reason a third party market exists for this data.

What it actually costs

The parser is an afternoon. The real cost is sessions. eBay has required a signed in account to see sold search results since around the middle of 2026, so the job becomes account management: real accounts, keeping them signed in, addresses that hold up, handling challenges, re-auth when they fail. That is an operations problem with a monthly bill, and no tutorial covers it because it is not fun to write about.

I work on an API that runs that layer, so take the conclusion with the appropriate amount of salt. But the status codes above are reproducible in about five minutes, and I would rather publish the control case (active search, same headers, 200) than imply eBay blocks everything, because it does not.

If you are starting this project: budget for the session layer rather than the parser, and test from the address your code will actually run on, not from your laptop.

I changed one parameter and the median moved 10x

Sam Smith — Sat, 17 Oct 2026 16:07:44 +0000

I went looking for one thing, failed to find it, and measured something more useful on the way. Both results are below, including the hypothesis that did not survive.

The setup

60 specific products across ten categories: graded cards, retro games, sneakers, watches, lenses, coins, tools, collectibles, consumer electronics. For each one, the same query twice, once over 90 days and once over 1,095 days, reading cleaned server side statistics rather than raw listings. 120 requests, paced.

The question: eBay's public sold filter shows about 90 days. How much of an item's sales record does that window hide?

The hypothesis failed

I expected thin 90 day windows and rich three year ones. Instead, 58 of 59 comparable queries already had eight or more clean sales inside 90 days. For the typical product, the 90 day window held essentially the whole visible record.

Only one query was genuinely starved: a complete copy of Earthbound on SNES, 6 sales in 90 days against 228 over three years.

The reason is not that eBay shows more than I thought. It is that a keyword search is broad. Ask for seiko skx007 dive watch and the window fills easily, because it fills with straps, bezels, crystals and cases as well as watches.

Breadth hides depth.

What showed up instead

Changing only the window changed the answer, often by a lot.

Change in median, 90d vs 3y	Share of products
10% or more	16%
25% or more	9%

The individual movers:

Query	90 day median	3 year median	Move
`rolex datejust 16220`	$435.56	$4,400.00	10x
`seiko skx007 dive watch`	$14.13	$200.00	14x
`marantz 2270 receiver`	$99.00	$710.00	7.2x
`mike trout bowman chrome 2009`	$4,750.00	$897.50	5.3x
`festool track saw ts 55`	$199.31	$325.00	1.6x

I checked the biggest one, because 10x usually means bug

Pulled both windows again and looked at listings instead of statistics.

Both windows return the same kinds of thing. Bottom of the distribution: a sapphire crystal at $23, a bracelet link at $39, an engine turned bezel at $84. Top: real watches at $4,500, $5,100, $5,700. Identical price deciles in both.

The three year set is the 90 day set plus 62 older sales, and those added sales sit high in the distribution. That drags the midpoint from the parts end of the list to the watch end.

So the market did not move. The composition of the match moved. Nobody's Datejust changed price by 10x, and anyone comparing those two medians would have concluded it did.

Why this is the more useful result

Price history gets sold on depth. More years, more data, better answers. Depth is real, and its actual value is sample size on scarce items.

But depth does nothing if the query is matching the wrong population, and widening the window can quietly change which population you are measuring. Retrieval is the problem. The time window is just another way to perturb it.

I measured the same failure from another angle recently: the same card search returned a $14.73 median raw and $545.00 once lots, proxies, accessories and "PSA 10 contender" listings were removed. That write up is here.

Four rules if you work with marketplace price data

Never compare medians across windows unless the filters are identical and tight. If the only thing you changed is the date range and the number moved more than a few percent, suspect the match before you believe the market.

Filter on parsed structure before you widen. Condition, grading fields, print run, category, and dropping lots and accessories. A tight match is stable across windows. A loose one is not.

Read the count alongside the median. If the median moved and the count jumped, you are looking at a different set of sales, not a trend.

Use depth for sample size, not for trend. Three years is the right tool for something that sells twice a quarter. For a trend, bucket sales by date and compare buckets. One long window median is a level, not a trend.

Reproducing it

Numbers are from a run on 17 October 2026. Capped queries, where the result hit the page size, are marked and excluded from the volume claims. Two of 59 were capped.

The free tier is 100 requests a month and no card, and count, used_for_stats, median, p25 and p75 come back on every response: compsapi.com/docs.

Your card pricing API is returning the median of a junk drawer

Sam Smith — Sat, 17 Oct 2026 15:58:11 +0000

Here is a measurement I ran on 17 October 2026 against my own API, which does not flatter it.

Search three years of completed eBay sales for charizard base set psa 10. Take the raw feed of sold listings, keep only the rows that sold a single unit, take the median:

$14.73, over 239 listings, with individual sales running from $1.30 to $30,000.

Run the same words through an endpoint that drops lots, mystery packs, accessories, replicas and keyword stuffed titles before it calculates anything:

$545.00, over 60 matching sales, middle half between $236.77 and $2,861.08.

Same words. Same window. Same marketplace. A 37x difference in the answer.

If you are building anything that prices collectibles, this is the whole problem in one example, and it is not specific to my data. Any tool reading the same eBay search sees the same listings.

Why the first number happens

eBay matches on words in the title, and it matches generously. A search for charizard base set psa 10 returns every listing whose title holds those words in any arrangement:

a card sleeve titled "fits PSA 10 Charizard Base Set"
a bulk lot of commons advertised as "Charizard Base Set PSA 10 chase"
a raw card described as a "PSA 10 contender"
a custom fan art proxy

None of those is the card. All of them are cheap, so they drag the middle of the distribution to the floor.

The difference between pricing tools is entirely in what they throw away after retrieval. Most throw away nothing and show you a median anyway.

The trap that looks like the fix

The obvious response is to put more words in the query. Add the card number:

q=charizard base set psa 10 4/102   ->  median $555.50

Looks like it worked. It did not work, it moved. The range is still $4.00 to $35,000, which tells you the set is still full of things that are not the card.

Two things go wrong when you push identity into the query string:

More words makes eBay widen, not narrow. You get a different population of wrong listings rather than a clean population of right ones.
Card numbers are reused across sets. 4/102 is Base Set Charizard and it is also a later anniversary reprint. Pinning the number without pinning the set pins nothing.

What actually works: filter on structure, not words

Parse the title into fields, then filter the fields. Grading company, grade, graded status and a junk classifier do almost all of the work:

curl -G https://api.compsapi.com/v1/comps \
  -H "Authorization: Bearer YOUR_KEY" \
  --data-urlencode "q=charizard base set" \
  --data-urlencode "graded=true" \
  --data-urlencode "grader=PSA" \
  --data-urlencode "grade=10" \
  --data-urlencode "days=1095"

{
  "stats": {
    "count": 60,
    "used_for_stats": 57,
    "median": 545.0,
    "p25": 236.77,
    "p75": 2861.08,
    "outliers_removed": 3
  }
}

The classifier flags that matter in practice, each one a listing class that will quietly wreck a median:

Flag	What it catches
`lot`	More than one card sold together
`mystery`	Repacks and "chance to win a PSA 10" listings
`accessory`	Cases, sleeves, binders, display stands
`replica`	Customs, proxies, fan art
`keyword_stuffing`	Several graders named with no grade, to catch searches
`not_graded_claim`	Raw cards described as a "PSA 10 contender"

To pin a specific card inside a set, filter after retrieval rather than before it. A post-search filter can only ever remove rows, so the effect is auditable. Text in the query changes which rows come back at all, so it is not.

Three rules if you are building this

Never ship a median without its sample size. A median of three sales is an anecdote. Return count next to it and let the caller decide.

Return the spread. In the cleaned set above the middle half ran $236.77 to $2,861.08. That is not noise to average away, it is the market. A nominally identical slab does not fetch the same price in a quiet week as it does with good photos and a seller with feedback. p25 and p75 are cheap to compute and they stop your users trusting a point estimate they should not.

Treat an empty window as missing data, not a low price. eBay's public sold filter reaches back about 90 days. For anything scarce that window is often empty, and the reflex is to loosen the query until something appears. What appears is a different item.

The part nobody can see at all

One more thing that silently biases every price model built on eBay sold data: when a sale completes as an accepted Best Offer, the public sold page keeps showing the asking price, not what the buyer paid.

I matched 5,859 accepted offer sales against what the public page displayed for the same listing. 99.0% read high, by a median of 14.9%, with the top tenth over 40%. Full numbers and method: compsapi.com/best-offer-gap.

That error is one directional. It never cancels out, and the data itself will never show it to you.

Reproduce it

The free tier is 100 requests a month, no card, every filter on. The numbers above reproduce: compsapi.com/docs.

And if you only take one thing from this: ask any pricing tool how many sales its number rests on, over what window, and what it discarded. If it cannot answer all three, it is showing you the median of a junk drawer.

Your eBay sold-price data is 14.9% too high and the response looks fine

Sam Smith — Sat, 10 Oct 2026 16:42:41 +0000

If your code reads eBay sold prices, it has a bug you cannot see. Not a parsing bug. The number comes back well formed, plausible, in the right currency, and wrong.

I run CompsAPI, so I hold both the asking price and the accepted price on the same sale. That let me measure the gap instead of guessing at it. Here is what came out, and why no amount of better scraping fixes it.

The failure mode

When an eBay listing sells through an accepted Best Offer, eBay's public sold page shows the asking price. The amount the buyer actually paid is not on that page. There is no field holding it, no query parameter that reveals it, and no header that hints the row is affected.

So the sale closed at $15,500, the page says $24,995, and your parser returns $24,995 with no error. Every tool reading that page returns the same wrong number, which is worse than disagreement, because when two sources agree you stop checking.

What I measured

Over the 90 days to 10 October 2026: 5,859 completed Best Offer sales across 5,840 distinct listings, from 93 searches in 12 categories. Every pair is matched on listing id, so the asking price and the accepted price belong to the same item on the same sale. No row was discarded.

99.0% read high on the public sold page. 0.7% match within half a percent, 0.4% read low.
Median overstatement 14.9%. A typical Best Offer sale shows about a seventh above what it closed at.
p90 40.8%. One sale in ten is overstated by more than two fifths.
Money weighted 14.2%, across every dollar that changed hands, so this is not an artifact of cheap items.
Median accepted price $240, against a median asking price of $284.

How the tail behaves, which matters more than the median if you are setting a ceiling:

Overstated by more than	Share of accepted Best Offer sales
5%	89.2%
10%	68.9%
25%	23.4%
50%	5.9%
100%	0.8%

By category

Every one of the 12 categories sits above 11% money weighted. The ones where sellers list high and expect to negotiate are the worst.

Category	Sales matched	Read high	Median gap	p90	Money weighted
Auto parts	228	96.9%	12.2%	51.3%	23.9%
Sneakers	857	99.9%	20.0%	50.0%	22.0%
Graded trading cards	390	99.7%	15.7%	40.0%	17.3%
Jewellery	652	99.1%	17.6%	55.6%	16.8%
Designer handbags	723	98.9%	17.5%	46.7%	15.8%
Video games and consoles	446	99.8%	14.7%	36.4%	15.7%
Phones and tablets	300	99.7%	10.0%	35.9%	15.3%
Golf clubs	599	99.3%	13.7%	33.3%	14.5%
Musical instruments	365	98.4%	13.2%	33.3%	14.4%
Coins and bullion	362	98.1%	11.1%	30.0%	13.2%
Luxury watches	655	98.0%	11.2%	31.2%	12.1%
Cameras and lenses	282	97.9%	11.1%	25.0%	11.5%

Why a better scraper does not help

A Best Offer is a private negotiation. eBay publishes that the item sold and what it was listed at, and keeps the accepted amount off the public record. This is not a rendering quirk or a lazy loaded element. The number is not in the page, so there is nothing to select.

That is the part worth internalising if you maintain a pricing pipeline: this is not a coverage problem you can close with more requests. It is a field that does not exist on the surface you are reading.

Why it does not average out

The instinct with noisy data is that errors cancel. These do not. A Best Offer is almost never accepted above the asking price, so the error is one sided and every affected comp pushes your estimate the same direction.

# The quiet version of this bug in a repricing loop.
comps = fetch_sold_comps(query)          # some read the public sold page
target = median(c["price"] for c in comps)
list_price = target * 0.97               # "just under market"

If a third of those comps were accepted offers reading a median 14.9% high, target is not the market, it is above it, and 0.97 does not save you. You sit high, the item does not move, and nothing in the data looks wrong. Four places it bites:

Repricing. You list against a level nobody paid.
Buying. You pay to a ceiling that was never real, and the margin you modelled was not there.
Valuation and insurance. Values come out high in exactly the categories people insure: graded cards 17.3% and jewellery 16.8% money weighted.
Anything trained on the data. A model fed asking prices learns a price level that never cleared.

Getting the accepted figure

price is what the sale closed at, and best_offer flags which rows were negotiated, so you can measure your own category rather than taking my median for it:

curl -G https://api.compsapi.com/v1/sold \
  -H "Authorization: Bearer YOUR_KEY" \
  --data-urlencode "q=charizard psa 10" \
  --data-urlencode "days=1095" \
  --data-urlencode "best_offer=1"

best_offer=only returns negotiated sales alone, which is the query that produced the tables above. In Python, the gap on your own data is about six lines:

import requests, statistics

r = requests.get("https://api.compsapi.com/v1/sold",
                 headers={"Authorization": "Bearer YOUR_KEY"},
                 params={"q": "charizard psa 10", "days": 1095, "best_offer": "only"})
sales = r.json()["items"]
print(len(sales), "negotiated sales")
print("median accepted", statistics.median(s["price"] for s in sales))

There is also an opt in best_offer=verify mode that returns a best_offer_confidence of confirmed, likely, unlikely or unknown per row, plus the asking_price and asking_gap_pct it reasoned from, so you can set your own threshold instead of inheriting mine. It costs extra upstream reads, so it is off by default.

Free key is 100 requests a month, no card. That is enough to reproduce this on one category.

What this does not say

It is 93 searches in 12 categories over 90 days, not a census of eBay. Other categories will differ.
It measures accepted Best Offer sales only. It says nothing about what share of all eBay sales go through an offer, which varies enormously by category. The 14.9% applies to affected rows, not to your whole dataset.
Three rows of 5,859 have an accepted price under $5 and are almost certainly an opening bid or a bad parse. Dropping every row under $10 moves the median from 14.9% to 14.8% and the money weighted figure from 14.2% to 14.0%, so nothing rests on them.
0.4% of pairs read low. I report that rather than filtering it out.
Where one listing sold several units in the window, the accepted figure is the average of that listing's accepted offers. In these categories almost every listing is a single item.

Full tables and method: compsapi.com/best-offer-gap.

If you maintain something that prices off eBay comps, the useful takeaway is not my number. It is that the error exists, it is one sided, and it is invisible in the response, so it is worth measuring on your own categories rather than assuming it is small.

How to get eBay sold listings data in 2026 (findCompletedItems is dead)

Sam Smith — Sat, 10 Oct 2026 01:19:48 +0000

If you build anything that needs eBay sold prices, 2026 broke your stack twice. Here is the current state of every route to completed listings data, and working code for the one that still works.

Full disclosure up front: I run CompsAPI, which is one of the options below. The rest of this post is accurate whether or not you use it.

What actually happened

A short timeline, because half the tutorials online are now wrong:

2020: eBay deprecates findCompletedItems, the Finding API call everyone used for sold listings.
February 2025: the whole Finding API is decommissioned. Code that called it gets security errors, not data.
The official replacement, the Marketplace Insights API, is a limited release. You apply with a business case, and approval is restricted to established eBay partners. Most applications go nowhere, and the developer forums are full of people stuck at the same wall.
Mid 2026: eBay puts the public sold listings filter behind a login. The LH_Sold=1 URL that every scraper and browser extension relied on now redirects to a sign in page for most traffic.

So the two free routes, the official API and scraping the public page, are both gone. What is left:

Option 1: Terapeak, if a human is doing the looking

eBay's own research tool (now called Product Research, inside Seller Hub) shows up to three years of sold data. If you price items by hand a few times a day, it is genuinely good and costs nothing extra with a seller account.

It stops at the browser: no API, no export of research results, and sellers report daily caps on queries. The moment you need sold prices in a spreadsheet, a pricing model or an app, there is no door.

Option 2: scrapers against the logged in page

Some scrapers now run eBay accounts to get through the login wall. Two structural problems. First, the public sold page shows at most 90 days of history. Second, when a sale closes as an accepted Best Offer, the page shows the asking price, not what the buyer actually paid. In offer heavy categories (watches, cards, anything expensive) those numbers run high by 20 to 40 percent per affected row. A scraper inherits both limits because the page itself is the ceiling.

Option 3: a sold listings API

This is what I build. One GET request, JSON back, up to 1,095 days of history per search, and on accepted Best Offer sales the price field is the real closing amount, flagged per row.

Get a free key at app.compsapi.com (100 searches a month, no card), then:

curl -G "https://api.compsapi.com/v1/sold" \
  -H "Authorization: Bearer sk_live_YOUR_KEY" \
  --data-urlencode "q=charizard psa 10" \
  -d "days=365" -d "best_offer=1"

Response, trimmed:

{
  "ok": true,
  "count": 239,
  "items": [
    {
      "title": "Charizard PSA 10 Base Set Holo",
      "price": 1450.0,
      "best_offer": true,
      "last_sold": "2026-10-04 18:32",
      "format": "FIXED_PRICE",
      "shipping_cost": 12.5,
      "url": "https://www.ebay.com/itm/..."
    }
  ],
  "next_page": true
}

That best_offer: true row is the point. On the eBay page this sale displays its asking price. Here it is the amount it closed at.

The Python version

There is a zero dependency client (github.com/compsapi/compsapi-python):

pip install git+https://github.com/compsapi/compsapi-python.git

from compsapi import CompsAPI

api = CompsAPI("sk_live_YOUR_KEY")
r = api.sold("iphone 14 pro 256gb", days=365, condition="used")
prices = sorted(s["price"] for s in r["items"])
print(f"{r['count']} sales, median ${prices[len(prices)//2]}")

Three years of price history in 15 lines

The thing you could never do with the public page, since it stops at 90 days:

from collections import defaultdict
from statistics import median
from compsapi import CompsAPI

api = CompsAPI("sk_live_YOUR_KEY")
monthly = defaultdict(list)

for sale in api.iter_sold("iphone 14 pro 256gb", days=1095, max_results=3000):
    monthly[sale["last_sold"][:7]].append(sale["price"])

for month in sorted(monthly):
    print(month, round(median(monthly[month]), 2), f"({len(monthly[month])} sales)")

Output is a monthly depreciation curve built from real completed sales. Each page of 240 sales costs one request, so a three year pull like this uses about a dozen requests.

If you want a pre-aggregated answer instead of rows, /v1/comps returns a cleaned median, the spread and the newest matches in one call, with lots, bundles and wrong model junk filtered before the math runs.

Honest limitations

eBay US is the primary marketplace, with matching sales from UK, DE, FR, IT, ES, CA and AU merged in or pinned with site=.
No seller information on rows.
The free tier is 100 requests a month. Paid plans start at $9.

If you came here from dead code

Migrating from findCompletedItems: your keywords becomes q, EndTimeFrom/To becomes days, entriesPerPage becomes size (max 240 instead of 100), and the response is flat JSON instead of a SOAP envelope. There is a field by field mapping at compsapi.com/replace/findcompleteditems.

Questions welcome in the comments. If you hit something the API does not cover, tell me and there is a decent chance it ships.