Main non-admin routes
GET /api/packsGET /api/packs/[id]POST /api/packs/[id]/purchasePOST /api/packs/[id]/openGET /api/packs/[id]/oddsGET /api/user/packsGET /api/user/packs/openedGET /api/user/collectiblesGET/PUT /api/user/featured-collectiblesGET/POST /api/binders,GET/PATCH/DELETE /api/binders/[id]POST /api/binders/[id]/verify-pinGET /api/v1/cards/[id]/provenance
Runtime behavior highlights
- Pack browse routes expose currently available packs and pack metadata.
POST /api/packs/[id]/purchasestarts a purchase.PUTon the same path always returns410 GONE. Confirmation moved toPOST /api/checkout/crypto/verify.- Purchase start records pack purchase state for the user. Free packs are limited to 3 purchases per user per UTC day.
- Open route resolves collectible outcomes and updates user ownership/inventory state.
GET /api/user/packsstatus is authoritative (pending|processing|opened|completed). TemplateisOpenableis not per-purchase state.- User collectible and pack routes expose owned content for client rendering.
- Featured collectibles expose a public showcase; authenticated replace is capped at 12 slots.
- Binder routes (
/api/binders*) are in the generated OpenAPI. Cover upload isPOST /api/upload/binder-cover. - PIN binders require
x-binder-pin-tokenfrom verify-pin. Without it,GET /api/binders/[id]returns403 PIN_REQUIREDand metadata only. GET /api/v1/cards/[id]/provenanceis public and returns{ card, currentOwners, transfers, mints }.
Side effects and dependencies
- Purchase/open flows may integrate with checkout, wallet, and minting subsystems.
- Historical fix/backfill scripts exist for pack purchase and rarity correction scenarios.
Known caveats
- Deterministic guarantees depend on pack configuration integrity and weighted content setup.
- Open and purchase flow state transitions can require reconciliation in rare partial-failure cases.
Exclusions
- Admin collectible/pack creation and stock management flows are excluded.
