PSA Population Reports & Change Tracking

Get grade-by-grade population data for an entire PSA card set, or track selected cards over time. Export JSON, CSV, or Excel for your own research, inventory tools, and dashboards.

New: population-change tracking. Save a watchlist once, then run it again to get net changes in total population, PSA 10, PSA 9, and the historical PSA 10 population share. Your baseline and observations are stored in your own Apify account.

Start with a set report

{
  "setUrl": "https://www.psacard.com/pop/tcg-cards/2024/pokemon-ssp-en-surging-sparks/285178",
  "maxResults": 10
}

A direct set URL is the most reliable input. setName searches for a matching set and can choose the wrong edition when names overlap; check its selectedUrl. Set reports do not require a PSA API token.

Sets containing only PSA/DNA autograph-certified cards return their counts in psaDnaPop, with populationType: "PSA_DNA" and psaPop: null. These counts are separate from regular PSA populations. Population-change tracking currently supports regular PSA cards only. When an API request uses maxResults or limit, that cap applies to card records; search details are saved as SEARCH-RESULTS in the run's key-value store.

Track a card or a set

Use a specID returned by the set report. This example follows one card:

{
  "setUrl": "https://www.psacard.com/pop/tcg-cards/2024/pokemon-ssp-en-surging-sparks/285178",
  "trackPopulationChanges": true,
  "watchlistName": "surging-sparks-watchlist",
  "watchSpecIds": [12168745]
}

1. The first successful run establishes a baseline. Change fields are null.
2. Run the same input again to compare against the previous successful observation.
3. To repeat automatically, save an Apify task and schedule it daily or weekly. This Actor does not create schedules or send messages itself.
4. Download results or use an Apify integration to send the rows to your own workflow.

Leave watchSpecIds empty to track every card in the set. Each returned card is billed, including unchanged cards and the first baseline. Use watchSpecIds for an inexpensive small watchlist. Changing the watchlist name or selected IDs starts an independent baseline. For tracking, leave maxResults at 0/unset; selecting cards explicitly keeps comparisons consistent. Do not run the same watchlist concurrently.

What you get

Every card retains specID, cardNumber, subject, variety, setName, year, psaPop, and the source observation timestamp. The population object includes grades, half grades, qualifiers, and total counts as available from PSA.

Tracking adds:

Field	Meaning
populationChangeStatus	BASELINE, UNCHANGED, CHANGED, CORRECTION, or NEW_TO_SET
deltaTotal	Signed difference in total reported population
deltaGrade10, deltaGrade9	Signed differences in these grade populations
gemRatePct	PSA 10 count divided by total population, as a percentage
gemRateChangePp	Change in that share, in percentage points
totalGrowthPct	Net total change divided by the previous total
baselineAt, observedAt, elapsedDays	The actual comparison window
netPopulationPerDay	Net total change divided by elapsed days
setUrl	Source set used for this observation

The run's key-value store includes POPULATION-CHANGE-SUMMARY. It records card counts, corrections, and previously present IDs missing from the current set. Complete observations are retained in your named psa-population-tracking-v1 store. They are accessible to subsequent runs of this Actor in your account.

Missing records are not reported as zero. Empty, incomplete, invalid, or mismatched snapshots fail tracking without replacing the baseline. Negative changes are preserved as corrections; they are not silently clamped.

Cert and spec-ID lookup

Use certNumber or certNumbers for certificate details. These lookups check cached records first. Missing, invalid, or older records may queue a browser refresh; the same run waits up to 120 seconds per distinct certificate, subject to its remaining time limit. If a valid record becomes available, the run returns it with fromCache: true and its original scrapedAt. A refresh may remain pending, be unavailable, or exceed the wait limit. A later run may find the completed refresh, but completion is not guaranteed. Repeated certificate numbers share refresh work within a run and retain their repeated output rows when successful.

Certificate lookups do not use a supplied apiToken. The optional secret token is used for uncached direct population lookups through specID; access depends on your PSA plan and source availability. Set reports and population tracking do not require it. An Actor fee does not buy a PSA subscription.

Cert and spec lookup results may reflect earlier population observations; the run timestamp does not guarantee that those populations were observed at that time. Use a direct set report or tracking for current set observations. Normal Actor result charges apply to all returned cards.

Pricing

See this Actor's Pricing tab for the current rate and any plan discounts. Tracking uses the same per-result price: one returned card is one result. For example, at $15 per 1,000 results, tracking 10 cards once a day for 30 days produces 300 results ($4.50 before applicable discounts or separately listed charges). Tracking 400 cards daily produces 12,000 results ($180). Named storage retention and subsequent downloads may incur Apify storage charges.

Limitations and troubleshooting

If a lookup returns no usable records, the run fails and saves its details under LOOKUP-ERROR in the run's storage. Error messages are not added to the result dataset. Batches that return some records keep those results and report failed or unattempted lookups in LOOKUP-SUMMARY.

• Tracking history starts when you first run the watchlist. No earlier history is invented or backfilled.
• PSA may correct, merge, split, or remove records. Population changes are net differences in reports, not a count of new submissions or unique physical cards.
• Gem rate is an observed population share, not the probability that an ungraded card will receive PSA 10.
• Different printings and varieties have different spec IDs. Check the set, card number, and variety before comparing cards.
• PSA site changes, blocking, or outages may prevent a run. Tracking requires a complete response and will keep the previous baseline if it cannot obtain one.
• If an ID is missing, retrieve a current set report and verify that it belongs to this exact set.
• Keep the named tracking store to retain baselines. Deleting it starts new baselines on later runs.

This independent tool is not affiliated with or endorsed by PSA or Collectors. PSA is a trademark of its owner. Data is provided for research and workflow automation.

Result completeness and timestamps

Certificate records can contain a population summary without a full grade-by-grade breakdown. populationDataStatus distinguishes breakdown, summary_only, and unavailable; unavailable counts are null, not zero. Responses without a usable card identity are excluded from paid result rows.

scrapedAt is the original data-observation time when known. servedAt, when present, records when the result was returned. A recent delivery time does not mean the underlying population was just refreshed.

Ordinary set lookups may return a complete observation up to seven days (168 hours) old by default; fromCache: true identifies reused records and their original scrapedAt is preserved. The input cacheDurationHours defaults to 168; choose a shorter age such as 24, or 0 to require a fresh lookup. Set reports and search aliases are always capped at seven days. Certificate lookups also default to seven days and honor shorter limits, including 0 to require a new observation for your queued request. Queued certificate refreshes never return observations older than seven days. Individual population lookups through specID retain their explicit caller overrides. Card identity is usually stable, but population counts can change during that period; use the original observation timestamp when assessing those figures. Search mappings with obvious sign-in or challenge placeholders are rejected; an exact set URL may still have a usable complete observation. Population-change tracking always requires a fresh, complete observation. An unavailable fresh lookup still fails rather than presenting an older observation as new data.

Ordinary lookup runs save a RUN-HEALTH summary in their run storage, including saved rows, failed/skipped lookups, and completion status. Failed lookups remain failed, and error details are kept out of the paid dataset. Aggregate operational counters record the build, outcome category, HTTP status, validation and cache-error counts. Private, bounded repair diagnostics can also retain a normalized set query, an exact public set URL or a certificate/spec identifier when needed to diagnose a requested cache miss. These records are separate from paid dataset results; API credentials and raw inputs or response bodies are excluded. Operational health reports have a 30-day retention window; repair evidence in the separate maintenance backlog may persist beyond that window. Historical reports may have less detail. A hard platform termination can prevent final diagnostics from being written.

Incomplete responses

If a later set page fails or the run reaches its time limit, valid cards already collected are saved with setResultStatus: "partial". The run's SET-LOOKUP-SUMMARY and LOOKUP-SUMMARY records explain what is missing; those summaries are not paid result rows. Population-change tracking requires a complete set and does not update its baseline from partial data.

Missing population counts are null, while a reported zero remains 0. Certificate identity may be available even when a full population breakdown is unavailable; check populationDataStatus before using grade counts. An uncached direct specID API lookup requires a PSA API credential you are authorized to use. Certificate refreshes can remain pending or unavailable; those failures are reported separately from paid result rows. Access denials and rate limits stop further requests to that source path for the run.