Skip to main content

Data Coverage

This page is for developers evaluating whether the Trading Card API fits what you are building. It states what the catalog contains, what it deliberately does not, what the access limits are, and what /v1 guarantees today — so you can qualify yourself in or out without talking to anyone first.

All counts below are fetched live from the API's own /v1/stats/counts endpoint. Nothing on this page is a hand-typed number.

What's in the catalog​

Loading catalog counts…

The catalog is organised around four core entities — sets, cards, players and teams — and the relationships between them. A set is a checklist; a card is a specific entry on that checklist; players and teams are the subjects cards resolve to.

Coverage is broadest in the major North American sports, and the model itself is sport-agnostic: genres and set types are data, not hardcoded categories, so non-sport releases use the same structures. Checklist depth varies by release — the modern era is the deepest, and coverage thins as you go further back. Rather than claim a uniform depth we do not have, we suggest querying the sets you care about directly; the set types concept guide explains how sets, parallels and inserts relate.

For where the data comes from and how it is validated, see data provenance.

What's not in here​

These are product boundaries, stated plainly and up front so you do not discover them three days into an integration.

  • No transaction data of any kind. No sold prices, no sales history, no Best Offer data, no marketplace provenance. This is not a roadmap gap or a "coming soon" — pricing and sales are out of scope for this product. If your application needs comps or market values, you will need a separate source.
  • No populated image data. The CardImage model, its endpoints, and the CDN and responsive-delivery plumbing all exist and are documented — see working with images, responsive card images, CDN integration, and uploading card images — but no image data is currently populated. Treat those docs as a description of the interface, not of available content, and do not plan around card images being there today.
  • No raw vs graded status, and no certification data. There are no grades, no grading-company records, no cert numbers, and no population data. The catalog describes cards as issued, not individual graded copies.
  • Memorabilia is set-level only. A set carries is_relic, but there is no card-level relic flag, so you cannot ask "is this specific card a relic?" — only "does this set contain relics?"

Identity and structure​

Stable IDs. Sets, cards, players and teams each have a stable identifier that is safe to store as a foreign key in your own system. Identifiers are not recycled.

Parallels, variations and inserts. These are modelled at two levels. A set carries is_parallel, is_variation and is_insert flags describing what kind of release it is. A card carries parent_id, which ties a parallel or variation back to the base card it derives from — so you can collapse a card and all its parallels into one logical item, or walk the other way and enumerate every variant of a base card.

Serial numbering. Serial-numbered releases record their print run, so limited parallels are distinguishable from open-ended ones.

Autographs. Recorded at both levels, and the distinction matters: has_autograph on a card marks that specific card as autographed, while is_autograph on a set marks the whole set as an autograph release. Check the card-level flag when you need per-card truth.

Memorabilia. is_relic exists at set level only, as noted above.

Field-by-field detail lives in the API models reference and the set types concept guide; this page describes the shape rather than duplicating those tables.

Access limits​

Your limit depends on which credential you call with:

  • Anonymous requests: 100 per hour.
  • OAuth tokens and Personal Access Tokens: 2,000 per hour.
  • Subscriber API keys: your plan's daily allowance — 1,000 requests per 24 hours on Starter, 10,000 on Pro, and 10,000 during the trial. See pricing.
  • Custom limits: available per client — get in touch if your use case needs more.

There is no monthly quota and no per-minute burst limit; the allowance above is the whole budget. Reading this page and browsing the docs requires no authentication at all. For rate-limit response headers, backoff behaviour, and practical strategies for staying under the limit, see the rate limits guide.

Versioning​

/v1 is the stable surface. Every endpoint documented on this site is a /v1 endpoint, and it is what you should build against today.

A /v2 prefix exists but currently exposes a single endpoint. It is not a general migration target, and there is nothing to move to yet.

We do not currently publish a formal deprecation policy — no committed notice period, no guaranteed sunset window. We would rather say that plainly than imply a guarantee that does not exist yet. Breaking changes to /v1 are documented in the API changelog.

Still deciding? Join the founding list — or reach out with a coverage question this page did not answer.