Skip to main content
A GemRate ID is GemRate’s unique identifier for a card as cataloged by a single grading company. It’s the key you use across the API: it’s returned by cert and spec lookups, and it’s what GET /v1/cards/{gemrate_id} takes.

One card, up to four IDs

Each grading company — PSA, Beckett, SGC, CGC — catalogs cards independently, so GemRate mints a separate ID per grader. A single real-world card therefore has up to four GemRate IDs, one for each grader’s entry. Each ID means “this card, graded by this grader.”

The universal ID

When GemRate recognizes that several per-grader entries are the same card, it matches them together and promotes one of those IDs to be the universal GemRate ID — the single identifier that represents the card across every grader. A grader-scoped response carries both:
  • gemrate_id — the grader-scoped ID for the entry you looked up.
  • universal_gemrate_id — the promoted, cross-grader ID for the same card.
The universal ID is itself one of the card’s per-grader IDs (the promoted one). So for the promoted grader gemrate_id and universal_gemrate_id are identical, while the other graders’ gemrate_ids differ from it.

Which field you get depends on the endpoint

The same value goes by different names depending on whether the endpoint is looking at a single grader’s copy or at the card as a whole:
  • Grader-scoped lookups — e.g. GET /v1/certs/{grader}/{cert} — return both, because you’re looking at one grader’s copy of the card. Here gemrate_id is that grader’s entry and universal_gemrate_id is the matched cross-grader card, so the two can differ.
  • Card-scoped endpoints — e.g. GET /v1/cards/{gemrate_id} (and specs / history) — deal with the card as a whole, so they expose a single gemrate_id field, and there that value is the universal ID. There’s no separate per-grader entry in view, so we don’t repeat it as universal_gemrate_id.
So gemrate_id doesn’t always mean the same thing: on the cert endpoint it’s a grader’s entry (with universal_gemrate_id alongside it); on the card endpoints it’s the universal ID. When you have both, prefer universal_gemrate_id to follow the card across graders.
For an unmatched card — only one grader has it, or matching hasn’t run yet — universal_gemrate_id may simply equal that entry’s gemrate_id. The two can differ, so keep both and don’t assume they’re equal.

Which one should I use?

  • Use universal_gemrate_id for the cross-grader view — combined population across PSA, Beckett, SGC, and CGC, comparable on the universal grade scale. GET /v1/cards/{universal_gemrate_id} returns the merged card.
  • Use a specific gemrate_id when you care about a single grader’s entry.
Both are accepted anywhere the API takes a {gemrate_id} path parameter.

Example

A 1986 Fleer Michael Jordan #57 graded by all four companies:
GraderGemRate ID
PSAabc123…← promoted to universal
Beckettdef456…
SGCghi789…
CGCjkl012…
After matching, all four entries report universal_gemrate_id = abc123…, while each keeps its own grader-scoped gemrate_id.
How do per-grader entries get matched into one universal card? A companion guide on the matching process is coming next.