Skip to main content
In development. 86d is being built in the open. Every capability is Experimental until it earns evidence, so check maturity levels before you rely on anything here.
The Storefront is what your Shoppers see. It is a Next.js application, and every page in it is an MDX file from your active Template, which means changing your homepage is editing a text file rather than fighting a page builder. Components from your enabled Modules, such as <ProductGrid />, <Cart />, and <NewsletterInline />, register themselves when you enable the Module. You place them in MDX the way you place a paragraph. No imports, no wiring.

​
Routes come from files

The global layout.mdx wraps every page with your <StoreNavbar />, the <Cart /> drawer, and <Footer />.

​
Place components in MDX

Once a Module is listed in config.json, its components are in the MDX registry everywhere:
index.mdx
products/[slug]/layout.mdx
Props flow in from the page’s rendering context. A detail page gets props.slug from the URL without you passing it.

​
Buying without an account

A Shopper can buy without creating a Customer account. Both paths work:
  • Guest: the Cart is keyed to a guestId held client-side. Items stay for 7 days, adjustable through moduleOptions in config.json.
  • Signed in: the Cart attaches to the Customer’s customerId. A Guest Cart merges into it at sign-in, so nobody loses what they picked out.
The Storefront never takes a Customer’s identity from the request body. On every authenticated request, the session decides who the Customer is. A request that claims to be someone else is a request from an attacker.

​
The Store API

Each enabled Module mounts its public endpoints under /api/, handled by the catch-all route at api/[...path]:
You never register a route by hand. Enable the Module, run 86d generate.

​
Rate limits

The API applies separate limits to general, sensitive, and Store Admin routes. A request over the limit returns HTTP 429 with retry headers. Current values are in the security model.

​
Overriding a component

The MDX registry merges components from four sources. When two export the same name, the later one wins:
  1. UI primitives
  2. App components: <Navbar />, <Footer />, <Logo />
  3. Module components, generated from what you enabled
  4. Per-page overrides
That last layer is how you replace one Module’s component on one page without forking the Module.
86d generate components lists every component available in your current setup. In this workspace it writes to public/internals/docs/component-api.md.