Commerce
Products are model records, the cart is a public mutation namespace your storefront calls, and orders live in the admin.
cmssy ships a cart, orders, discounts and an order pipeline. None of it is a separate product area: a product is a model record, the storefront talks to the same delivery API as everything else, and the order desk is the admin.
The capability is a plan flag - canUseCart in get_workspace_info - so read it rather than assuming.
Products are records
There is no product type in cmssy. You create a model - product, plan, ticket, whatever your catalogue is - and the workspace's cart config maps that model into the cart through a product source: which model, which field is the price, which is the stock, which are the variants.
That is why a catalogue can come from more than one model at once, and why the same block that renders any other record renders a product.
What the storefront can call
The cart namespace is public: no token, session-scoped, the one part of the delivery API that writes.
cart.get(workspaceId)- items,subtotal,tax,shippingTotal,discountedTotal,totalGross,currency,pricesIncludeTax,availableShippingMethods,appliedDiscount,taxSummary.cart.addItem-{ recordId, quantity, variantSelections, notes }. The item is a reference to the record, not a copy of it.cart.updateItem,cart.removeItem(itemId),cart.clear.cart.applyDiscount(code),cart.removeDiscount,cart.setShippingMethod(shippingMethodId).cart.merge- folds an anonymous session cart into the signed-in member's after login. Call it once, right after authentication.cart.checkout-{ customerEmail, customerNote, poNumber, shippingAddress }turns the cart into an order.
Totals come back computed. Do not add up line prices in the browser: tax mode, discounts and shipping are decided server-side, and a second implementation in your frontend is a second answer.
Order status without an account
public.order.byToken returns one order - orderNumber, items, paymentStatus, fulfillmentStatus, amountPaid, balanceDue, invoiceUrl - for the token issued at checkout. That is how a "track your order" page works for a guest.
What the workspace configures
public.siteConfig.publicCart is the storefront-safe projection of the cart settings: defaultCurrency, pricesIncludeTax, taxRates, shippingMethods, productSources, maxItemsPerCart, maxQuantityPerItem, enableSavedCarts, enableQuoteRequests. Read it once and let it shape the UI - currency formatting, quantity limits, whether a quote request is offered at all.
Orders are back-office
Everything after checkout is authorized: the admin, or the MCP server with a token whose role allows it. Orders can be listed and read, created by hand, edited line by line, marked paid in full or in part, refunded, canceled, moved through fulfillment, given an invoice, and moved along a configurable pipeline. Discounts are created, updated and switched on or off the same way; products can be bulk-updated, bulk-deleted or given price tiers.
Payment providers are not part of this: cmssy records what happened - mark_order_paid, record_order_payment, refund_order - and your integration decides when it happened.
Next steps
- Data models - the records a catalogue is made of.
- GraphQL delivery API - how a public write is scoped.
- Webhooks - the ten
order.*events.