Standing up a shop is not hard any more. What stays hard is everything downstream of the order: the customer record, the invoice, the fulfilment, the refund, the support ticket that refers to all four.
The storefront here is not a separate product with its own database. It is a set of endpoints over the same records the rest of the platform uses.
The catalogue
Products, categories, collections, brands and attributes are all readable through one consistent surface:
GET /storefront/products
GET /storefront/product/:id
GET /storefront/product/:id/related
GET /storefront/categories
GET /storefront/collections/:collection
GET /storefront/brands/:brandSite data for a storefront is public by design — a shop nobody can read before signing in is not a shop.
GET /storefront/data/:siteId (no auth)Cart and checkout
GET /storefront/cart/get/:authorid/:cartid
POST /storefront/cart/update/:cartid
GET /storefront/cart/clear/:cartid
POST /storefront/checkout-cartA cart belongs to an author, which is what lets a signed-in customer keep one across devices instead of losing it with the browser session.
The part that usually costs you
An order is not the end of a transaction, it is the start of several. On this platform those are not integrations you build:
- The buyer is a customer record the CRM already knows
- The payment produces an invoice finance can see
- Fulfilment is a work item with stages and an owner
- A support ticket about the order can reference the order
None of that requires syncing, because there is nothing to sync between. That is the whole argument for a shared data model, and it is worth more than any individual feature in the list above.
Read next
- Storefront API — the full endpoint surface
- Storefront in Studio Manager — the same thing with screens
- Finance — invoices and payments