Data sources and pricing strategy

Date: 2026-05-13. Status: canonical data and pricing strategy. Source migration: condensed from poc-tcg-collector/doc/COMPETITOR_DATA_SOURCES.md, POKEMON_API_REVIEW.md, and PTCG_ASSETS_REVIEW.md.

Core model

There is no single perfect TCG data source. Serious apps combine four layers:

1. Community metadata feeds: cards, sets, names, numbers, images.
2. Marketplace feeds: SKUs, prices, sealed products, graded prices, sale/listing context.
3. Gap-filling sources: publisher pages, community wikis, asset repositories, manual curation.
4. User correction loop: users report missing or wrong items and build the long tail over time.

SKN should embrace this model explicitly. The product moat is not owning every upstream feed. The moat is normalizing them, explaining confidence, and making corrections operational.

Current source roles

Layer	Source	Role
Card metadata	TCGdex	Primary Pokémon card metadata and multilingual catalog
Card images	TCGdex / local cache	Current card image source, rehosted from our stack
Sealed product exploration	1niceroli/ptcg-assets	Internal POC imagery and catalog-shape reference only
Sealed + pricing candidate	pokemon-api.com / RapidAPI tcggopro	Candidate commercial source for sealed products, Cardmarket, TCGPlayer, and graded data
Sold comps	eBay APIs or controlled ingestion	Future source for sale-based pricing confidence
EU market	Cardmarket	Long-term direct source target, currently via upstream/provider options
FR peer-to-peer	Vinted / Leboncoin	Later premium signals, not MVP dependency
Graded sanity checks	PriceCharting, graded providers, GCC-style last-sold signals	Future graded estimate inputs

Pokémon-specific stance

For Pokémon cards:

• TCGdex remains the primary catalog feed because it is free, multilingual, and already integrated.
• pokemon-api.com is a strong candidate for sealed products, graded data, and market prices, but the actual terms, response shape, caching rights, and quotas must be verified before production reliance.
• ptcg-assets is useful for internal sealed scanning experiments but not production asset distribution unless permission or licensing changes.

For sealed products:

• do not force sealed items through the raw card schema;
• model product type, set, language, region, image source, and product identifiers separately;
• keep source provenance on every product and image;
• cache assets only when terms allow it.

Pricing principles

SKN should publish estimates, not magic prices.

Each price observation should keep:

• source;
• URL or external ID;
• observed price;
• currency;
• sale/listing date;
• sold vs active listing;
• condition;
• language;
• region;
• raw / graded / sealed item class;
• grader and grade when relevant;
• shipping and fee treatment when known;
• confidence flags.

Estimate rules:

• sold data weighs more than active listings;
• recent data weighs more than old data;
• same-region and same-language data weighs more than mismatched data;
• Cardmarket asks, eBay sold comps, and graded sources are different signals, not interchangeable truths;
• raw, graded, and sealed estimates must be separate;
• low-liquidity estimates must show lower confidence;
• every estimate should be explainable in the UI.

Provider risks

Risk	Impact	Mitigation
No license on asset repository	Cannot safely redistribute assets in paid production	Use only for internal POC, seek permission or replace
API quota or pricing changes	Imports or live pricing become unreliable	Cache observations, keep provider abstraction, retain backup sources
Provider outage	Prices or sealed records go stale	Store snapshots and show data freshness
Scraping terms risk	Legal and operational fragility	Prefer APIs or explicit permission for production
Hotlink protection	Images break or violate terms	Rehost only when allowed; otherwise use licensed/source-safe assets
Region mismatch	Users see irrelevant prices	Weight EU/FR data above US data for FR users

Implementation guidance

Build provider integrations behind normalized contracts:

• CatalogSource for cards and sealed products;
• ImageSource for source image provenance and cache rules;
• PriceObservationSource for market observations;
• PricingEstimator for weighted estimates.

Do not let mobile screens depend on provider-specific response shapes. The backend should return SKN-normalized objects with source/provenance metadata.

Immediate next steps

1. Pin scan-case feedback so wrong IDs become training and regression data.
2. Build a sealed lab catalog from a small, controlled source subset.
3. Create pricing observation and estimate tables before adding many providers.
4. Verify pokemon-api.com sealed product response shape, terms, image rights, and quota behavior.
5. Decide production-safe asset strategy before public paid release.

Related docs

• Product engine architecture
• Persona and positioning
• PRD feature map
• Scan UI/UX competitive review
• Asset licensing and source risk register