Storefront

The storefront is a Next.js app driven by MDX templates. Module components register automatically, so you compose pages like writing markdown.

The 86d storefront is a Next.js application that renders your store’s public-facing pages. Every page is an MDX file from your active template. Module components such as <ProductGrid />, <Cart />, and <NewsletterInline /> are registered automatically when a module is enabled, so you place them in MDX the same way you place any other element. No import statements, no boilerplate.

Key pages

The storefront routes map directly to MDX files in your template:

Route	Template file
/	index.mdx
/products	products/layout.mdx
/products/[slug]	products/[slug]/layout.mdx
/collections	collections/layout.mdx
/collections/[slug]	collections/[slug]/layout.mdx
/checkout	Multi-step Next.js route (info, shipping, payment, review)
/blog	blog/layout.mdx
/search	search/index.mdx
/track	track/index.mdx

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

Using module components in MDX

Once a module is enabled in config.json, its components are registered in the MDX component registry and available everywhere. You use them inline, just like HTML:

index.mdx

<FeaturedProducts limit={4} title="Staff Picks" />

<CollectionGrid featured />

<NewsletterInline source="homepage" />

products/[slug]/layout.mdx

<ProductDetail slug={props.slug} />

<Reviews productId={props.slug} />

<RecentlyViewed />

Props flow from the page’s rendering context into the MDX file. Detail pages receive props.slug automatically from the URL.

Guest vs. authenticated shopping

Customers can shop without creating an account. The storefront distinguishes the two modes transparently:

• Guest shopping: the cart is identified by a guestId stored client-side. Items persist for up to 7 days (configurable via moduleOptions in config.json).
• Authenticated shopping: after sign-in, the cart is attached to the customer’s customerId. Guest carts can be merged into an authenticated cart at sign-in.

The storefront never accepts a customer’s identity from the request body. Session data determines who the customer is on every authenticated request.

Store API

Every enabled module mounts its public endpoints under /api/. The storefront’s Next.js catch-all route (api/[...path]) handles all of them:

GET  /api/products
GET  /api/products/:slug
POST /api/cart
GET  /api/collections
POST /api/newsletter/subscribe

You do not need to configure routes manually. Enabling a module in config.json and regenerating is all it takes.

Rate limiting

The API enforces rate limits to protect your store from abuse. Limits apply per IP address on public endpoints.

Public endpoints: 120 requests per minute per IP

All standard storefront API calls (product listings, cart operations, collection browsing) are limited to 120 requests per minute per IP address.

Sensitive endpoints: 10 requests per 10 minutes per IP

Endpoints that could be abused for spam or fraud (newsletter subscribe and payment intent creation, among others) are restricted to 10 requests per 10 minutes per IP.

Rate limit response headers

When a client exceeds a limit, the API returns HTTP 429 with Retry-After and X-RateLimit-Reset headers so clients can back off gracefully.

Component registry order

The MDX component registry merges components from multiple sources. When two sources export a component with the same name, the later source wins:

1. UI primitives (base layer)
2. App components: <Navbar />, <Footer />, <Logo />
3. Module components, auto-generated from installed modules
4. Per-page custom overrides (highest priority)

This means you can override any module component on a specific page by passing a custom component as a prop to the MDX renderer.

To see all components available in your current setup, run 86d generate components. The generator writes apps/store/component-api.md with the full list of registered components and their props.