Ript Is The Inventory: A Partner API For Real Trading Card Pack Products

Trading card pack products are easy to describe and hard to run.

A partner can build a front-end pack picker, a payment step, a reveal screen, and a community campaign. The harder part is inventory. Someone has to source cards, check grades, reject auctions, match prices, prevent stale listings, manage claim locks, and handle what happens after a user wants the physical card.

That is the gap Ript can own.

Ript's partner message should stay clear: Ript is the inventory. You run the gacha, RNG, and player payments.

What The Ript Inventory API Provides

The Official Inventory API gives partners access to the core inventory primitives:

• GET /v1/inventory/catalog
• POST /v1/inventory/draws
• GET /v1/inventory/claims
• POST /v1/inventory/claims/:id/buyback
• POST /v1/inventory/claims/:id/fulfill
• GET /v1/inventory/ledger
• POST /v1/inventory/pack-preview

That set matters because a partner does not only need a card list. They need a full claim process. The catalog helps them build a pack. The draw endpoint locks a SKU. Claims show the exact card and economics. Buyback and fulfill provide the two settlement paths.

Why The Catalog Is Flat

Ript's catalog should not be described as a secret server-side rarity pool.

The partner catalog is a flat shared list. rarityBand is useful metadata for filters and pack-builder logic, but it is not the same as a hidden pool. Partners can decide how they want to use the catalog for their own product, within the API contract.

That distinction is important for developers. It keeps responsibility clean:

Layer	Ript owns	Partner owns
Inventory	Catalog, SKU identity, claim state, settlement rails	Pack selection logic and player experience
Payments	Claim fee, wholesale/fulfillment mechanics, ledger	Player charge model unless using a whitelabel lane
Trust	Official inventory gates and fulfillment path	Clear disclosure and front-end UX

The Claim Flow

A partner draw should be treated as a real inventory event.

When a partner draws by skuId, the SKU is locked for about 15 minutes. If the SKU is already taken, the API returns 409 sku_unavailable; Ript does not substitute a nearby card.

That behaviour matters. Substitution is convenient for software, but risky for collectors. If a user expects a specific card identity, grade, and market reference, the partner product should not silently replace it.

After the claim, there are two exits:

1. Buyback: the card returns to the list and the buyback economics apply.
2. Fulfill: the partner pays the full locked market amount so Ript can place the physical order.

The claim fee is billed either way: 15% of insured, with a $1.00 floor, on Net-30 terms.

Where Whitelabel Fits

The Inventory API is not the only partner motion.

Some partners will want to run their own pack logic and use Ript as a catalog. Others will want a branded pack experience that feels native to their site. That is where the whitelabel iframe and program partner route fits.

The whitelabel lane can host the pack picker, open, and reveal stage with partner branding. Inventory still settles through Ript. This keeps the partner's user experience flexible while preserving the inventory layer.

FAQ

Who is the Ript Inventory API for?

The Ript Inventory API is for partners that want to build trading-card pack experiences without becoming a card warehouse. They can use Ript's catalog and claim rails while running their own front-end experience, RNG, and player payments.

Does Ript run the partner's RNG?

For the invoice/API lane, the partner runs the gacha, RNG, and player payments. Ript provides inventory, claim state, buyback, fulfillment, and ledger endpoints. The whitelabel lane is separate and should be described separately.

Can a live API key be used in a browser?

No. Live keys should stay server-side. The product guide states that browser Origin plus a live key should return 403 live_key_browser_forbidden. Public examples should use sandbox keys only.

What happens if a SKU is unavailable?

If a SKU is taken, Ript returns 409 sku_unavailable. The API should not substitute another card. Partners need to handle that case in their own product logic.

Conclusion

A trading card inventory API is only useful when it handles the messy parts of real inventory. Ript's partner story is strongest when it stays operational: verified seats, flat catalog, SKU locks, clear claim economics, buyback, fulfill, and ledger visibility.

The simplest position is still the strongest one: Ript is the inventory.