Changelog

GET /v1/market/sales/export/csv now returns X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers alongside the file download — the same headers you already see on JSON responses.

X-RateLimit-Remaining reflects your remaining daily budget after the download is charged, so you can tell exactly how much headroom you have left without making an extra API call.

Starter plan now has a single shared daily budget of 100,000 rows. Every row you receive counts toward the same pool — whether it comes from a paginated JSON call or a CSV file download. Pull 60,000 rows today and you have 40,000 left, available as more API calls or a CSV download.

CSV downloads are now counted toward your budget. When you call GET /v1/market/sales/export/csv, the number of rows in the file is deducted from your daily total. Check X-RateLimit-Remaining after any call — it always reflects your true remaining budget.

Webhooks are now available as a self-serve add-on for Starter subscribers. Register up to 5 HTTPS endpoints and we'll push every new card sale to them within ~30 seconds of indexing — no polling loop required.

Each delivery is a signed batch of up to 1,000 records in the same schema as GET /sales. We retry 3 times with backoff (0s / 5s / 30s) on failure. If all three fail, your cursor holds and you pick up exactly where you left off on the next cycle — no missed records, no duplicates.

Webhooks do not include NRT (near-real-time eBay data). NRT remains a separate add-on available on Custom plans.

Cursor pagination is now available on every plan, including Free and Starter. Every response from /v1/market/sales now includes a next_cursor field in the pagination object when more results exist. Pass it as ?cursor= on your next request to fetch the next page — no offset drift, no missed or duplicated records as new data is indexed.

CSV export is now available on Starter and above. Hit GET /v1/market/sales/export/csv with the same filter params you'd use on /sales and receive a download-ready CSV file. Rows count against your shared daily budget (100K on Starter).

Both features require no integration changes if you're already on the API — just start using the new parameters.

Sales data from three major card auction houses is now live in the API. Results appear automatically in any search alongside eBay data — no integration changes required. Use ?platform= to query a specific house or omit it entirely to search across all sources at once.

The combined dataset covers 175,000+ completed auction lots from 2012 through today — over a decade of high-value card sales. It includes bid counts, lot images, direct links to each lot page, and parsed grade/grader fields for slabbed cards. This is the same underlying data serious collectors and dealers use to establish market value.

One important distinction: auction house prices are hammer prices — the amount called at close by the auctioneer. Buyers pay an additional buyer's premium on top (typically 20–22%). eBay prices in the API are all-in. If you're comparing prices across platforms, account for this difference.

Every sale response now includes shipping_price — the amount the buyer paid for shipping, separate from the card price. A free-shipping listing returns 0.00. When shipping cost was not disclosed by the seller, the field is null.

Filter by shipping cost with ?shipping_max=0 (free shipping only) or ?shipping_max=10 (shipping ≤ $10). Combine with price filters to compare true all-in costs across listings.

Coverage is approximately 67% of records. The remaining ~33% of listings did not publish shipping cost and return null.

The webhook delivery daemon shipped. It polls every 30 seconds and fans out to all registered endpoints per API key. Each batch is HMAC-SHA256 signed and retried three times with backoff (0s / 5s / 30s) on failure.

This update also added support for multiple endpoints per key (up to 5) via a new webhook_endpoints table — moving from a single URL column to a normalized per-endpoint model.

The catalog API is now in beta. Search and browse 13.8M cards across sports, years, sets, and player names — with structured flags for rookies, autos, relics, short prints, print runs, and more. Card images are served from our own CDN.

The catalog is a complement to the sales API, not a replacement. Use it to build structured lookups, enrich your own records with card metadata, or power a type-ahead search by player or set name. The Catalog API is an add-on available to any plan. Access is currently invite-only while we finalize pricing. Email hello@thecardapi.com to join the beta.

Every sale response now includes a print_run field — the denominator of the serial fraction stamped on the card. A card serialized /99 returns "print_run": 99. A 1/1 returns "print_run": 1. A base card with no serial number returns null.

Filter results directly with ?print_run_max=99 (any card numbered /99 or lower) or ?print_run_min=1 (1/1s only). Combine both to target a range — e.g. print_run_min=1&print_run_max=10 for ultra-rare single-digit print runs.

Approximately 36% of all records (6.2 million rows) have print_run populated. Coverage grows automatically as historical data backfills.

Every response from /v1/market/sales now includes 10 structured fields — player, sport, team, manufacturer, card_set, card_number, year, season, league, and features. These fields are populated where available from the original listing data. They will be null (or [] for features) when not present.

Coverage is currently limited to recent sales where structured listing data was provided by the seller. Coverage grows automatically as more listings include this data — no integration changes are required.

Searching for /10 now returns cards from a 10-copy print run — not PSA 10 grades. Searching for 47/100 now matches the exact serial-numbered card stamped 47 out of 100, not any record containing the number 47.

Two distinct search intents are handled separately: N/M (e.g. 47/100) targets the specific physical card with that serial stamp. /N (e.g. /10) matches any card from that print run. Both work identically in the playground and the market API.

Every record now includes price_confirmed. true means the price is the verified final transaction amount. false means the record was captured very shortly after close and the final price will be confirmed on our next daily run (within 24 hours).

Most use cases can ignore this. It matters most if you are building something that processes data continuously and needs to distinguish between an early capture and a settled transaction.

A full-text sales search — e.g. 'PSA 10 Mike Trout 2011 Topps Update' filtered by grade, grader, and date range — now returns in 3–5ms across 17 million records. The same query previously took 683ms.

This was a complete rewrite of the query backend. No API changes were required. All existing integrations benefit automatically.