snapcasterCore concepts
Platform and Seller
Section titled “Platform and Seller”A Platform is the external backend or POS a Seller connects through. A Seller is the marketplace participant whose Listings Snapcaster hosts. A Platform is not itself a Seller.
Canonical Catalog
Section titled “Canonical Catalog”The Canonical Catalog is Snapcaster’s master TCGplayer Product and SKU reference. A Product is one card printing, and a SKU is its exact condition, language, and finish variant. The Catalog supplies the descriptive name, set, condition, language, finish, and image for buyer Browse.
Listing
Section titled “Listing”A Listing is one Seller’s offer for one canonical SKU.
It carries price, On-hand, and an optional opaque externalRef that Snapcaster echoes back to the Platform.
Do not call this a Product, because Product means the canonical card printing.
Matched and unmatched
Section titled “Matched and unmatched”A matched Listing’s skuId resolves to the Canonical Catalog and can proceed toward Browse.
An unmatched Listing is stored but cannot be browsed until that SKU resolves.
GET /me separates matched and unmatched counts, while GET /listings explains the status per Listing.
On-hand, Committed, and Available
Section titled “On-hand, Committed, and Available”On-hand is the physical quantity asserted by the Seller’s Inventory source. For a platform-source Seller, your Platform owns and pushes this number.
Committed is the quantity sold through Snapcaster but not yet reflected in the Platform’s latest eligible On-hand snapshot. Snapcaster owns this number and uses it to prevent overselling between the sale and your next push.
Available is what a Buyer can purchase.
At the authoritative Checkout gate it is On-hand - Committed - Reservation; Browse shows the optimistic On-hand - Committed projection.
Available is derived and must never be pushed by a Platform.
| Event | On-hand | Committed | Browse Available |
|---|---|---|---|
| You push 4 | 4 | 0 | 4 |
| A Buyer purchases 1 | 4 | 1 | 3 |
| You push 3 after reflecting the sale | 3 | 0 | 3 |
The browsability gate
Section titled “The browsability gate”A matched, active Listing with positive Available enters Browse only when its Seller is active, not on vacation, has a Shipping option, has a Canadian payout-ready Connected account, accepted the current Seller Terms, completed tax and Canadian-origin declarations, uses native Checkout, and has authenticator-app two-factor enrollment.
GET /me returns the exact incomplete Seller prerequisites and actions.
The Browse operations are informational for Platforms. A Platform does not implement them.
Field tiers and forward compatibility
Section titled “Field tiers and forward compatibility”STABLE fields are frozen and safe to build against. A STABLE field’s shape will not change, but the field can still be optional when it does not apply.
PROVISIONAL fields are designed but not frozen. Parse them leniently, tolerate their absence, and do not depend on their exact shape.
Treat every payload as open.
Ignore unknown fields and event types instead of rejecting an otherwise valid payload.
Inbound requests use camelCase such as skuId and externalRef, while outbound webhooks use snake_case such as sku_id and external_ref.
Need help?
Email Marketplace support with this page and the sandbox environment prefilled.
Never include an API key or Signing secret in the message.