Sold and completed results now sit behind a sign in and reach back about 90 days, and the API calls that used to return them are switched off. Here is what still works by hand, why your tools broke, and what the number you see by hand gets wrong.
The same change shows up in several different ways, which is why it reads as a bug rather than a policy:
None of these are faults at your end. Sold data moved.
Sold results require a signed in session. Checking what something sold for means being logged in and clicking through items one at a time. Anything reading the page without a session gets nothing useful, which is why tools and spreadsheets broke first and quietly.
The history is short. The public sold view reaches back about 90 days. Anything older is not there to find, so seasonal comparisons and any item that sells a few times a year are out of reach by hand.
The API routes closed. findCompletedItems, the Finding API call that returned sold and completed listings for a keyword, was deprecated and then switched off, and the Finding API followed it. The official successor for sold data, the Marketplace Insights API, is a limited release restricted to approved partners, so most teams have no official route at all.
This still works and costs nothing. Sign in, search the item, and apply the sold filter in the results. On mobile the same filter sits under the filter control. Expect about 90 days of history, one item per click, and no way to export.
It is fine for checking a single item before you list it. It stops being viable the moment you need thirty items, a trend over a year, or the same check every morning.
Most third party price tools and every spreadsheet formula were reading the public sold page. When that page started requiring a session, the ones that did not hold a real logged in session lost their data source. Some now show thinner results than before rather than failing outright, which is worse, because a short page of comps looks exactly like a complete one.
If a tool you rely on suddenly agrees with you less often, or returns five comps where it used to return fifty, that is the symptom. Check the row count, not just the price.
There is a second problem that survives every workaround. When a listing sells through an accepted Best Offer, the public sold page shows the asking price, not what the buyer paid. The accepted amount is not on the page in any form.
We hold both figures, so we measured it across 5,859 matched sales: the public page read high 99.0% of the time, by a median of 14.9%, and one sale in ten was overstated by more than 40%. The error is one sided, because an offer is almost never accepted above the asking price, so it never averages out. Full tables by category are in the Best Offer gap study.
So pricing off what you can see by hand leaves you above the market in exactly the categories where people negotiate hardest.
One GET request returns up to 240 completed sales with the price, sold date, format and shipping, going back up to 1,095 days instead of 90, with the real accepted amount on Best Offer sales:
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"No eBay developer account, no approval process and no session of your own to maintain. A free key is 100 requests a month and needs no card. If you are replacing a specific thing that broke, there are field by field maps for findCompletedItems, Marketplace Insights and Terapeak.
If you would rather not write code at all, the Google Sheets template pulls the same data into a spreadsheet.
100 free requests a month · every filter on · no card
Get a free key