Marketplace API for listings, cart, checkout, and payouts

ChefSphere marketplace APIs are built for product teams that need real commerce flows—not a thin product catalog dump. You get surfaces for listings, cart, checkout, orders, returns, and payouts so buyers and sellers can complete transactions inside your app. The module sits beside seller KYC, wallets, and media so storefronts stay coherent without stitching five separate vendors together for one checkout journey.

This guide focuses on commerce intent: how a marketplace backend should behave when you ship discovery, purchase, fulfillment handoff, and seller money movement. It is not a food-app architecture overview and not a restaurant-vertical playbook; those topics have dedicated guides with different search intent. Here we stay on listings through payouts, and how prepaid token burn applies when checkout and order writes cost more than ordinary catalog reads.

Listings need structured detail, media references, and clear seller ownership that your clients can render without inventing schema mid-sprint. Cart and checkout need deterministic pricing snapshots, inventory-aware reservation behavior, and failure modes support can explain when stock moves. Orders, returns, and payouts need status paths tied to seller verification so money does not leave before policy allows it.

Reads stay cheap on the prepaid ledger while marketplace checkout writes sit in the heavier token-weight band because they mutate money and inventory state. That is intentional: you pay for operations that carry business risk, while browsing and catalog detail remain light for discovery-heavy sessions. Unused tokens stay on your balance across every ChefSphere module—not locked to commerce alone—so quiet browse weeks do not waste launch capacity.

During early access You request access, we review what you are building, and we contact you when keys and onboarding open for your markets and seller model. Docs today include illustrative OpenAPI shapes for planning; production contracts and environments follow once early access is granted.

Authentication is Firebase-style: an X-API-Key on each call, billed against your prepaid token balance shared across the platform surface. Starter packs begin at $29 for 200,000 tokens; Growth and Scale packs raise volume and effective rate across the July 2026 public band. One balance spends across marketplace, live, AI, social, billing, and the rest of the nineteen modules without a separate meter per feature.

Plan capacity around your mix rather than a single average call cost that hides checkout and KYC spikes during seller onboarding weeks. If your first release is browse-heavy with sparse checkout, a Starter pack may be enough to integrate and validate core commerce paths. If you expect concurrent checkout plus AI or live in the same month, Growth at $79 or Scale at $149 is the honest planning band.

Choose this module when commerce is the product spine: multi-seller listings, cart, checkout, returns, and payouts as the primary user journey. Choose the food-app backend guide when you need a composition of catalog, planning, social, and commerce under one product story. Choose the restaurant marketplace backend guide when restaurant discovery, menus, and operator workflows dominate instead of generic multi-seller patterns.

Request early access with a short note on seller model, geography, and whether you need KYC before first payout so we can prioritize onboarding. Related reading covers seller KYC, wallet currency, and restaurant marketplace backends so money path and vertical story are designed early. That preparation beats wiring a storefront against illustrative samples without a trust or payout plan your finance team can defend.