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.
Store Admin is where you run one Store. It lives at /admin inside the Store Runtime itself, which means it works whether or not you use the managed product, and it keeps working if 86d.app is down. Do not confuse it with 86d Console. Console is where you manage Businesses, Store records, billing, and deployments across the managed product. Store Admin is where you manage the actual Store: Products, Orders, Customers, content. Different surfaces, different authorities, both yours. An unauthenticated request to /admin redirects to /auth/signin.

​
Signing in

If you seeded demo data, use the credentials you set during 86d init. The defaults are admin@example.com and password123.
Change that password before the Store is reachable from the internet. The default is printed in these docs, which is exactly as safe as it sounds.

​
The sidebar builds itself

Navigation has two levels. Nine top-level groups are fixed; the subgroups under them come from whatever Modules you enabled. Each Module declares the group and optional subgroup its pages belong to, and the sidebar registry places them. @86d-store/orders lands under Sales → Orders. @86d-store/blog lands under Marketing → Publishing. There is no navigation config file for you to maintain, and no way for two Modules to fight over a slot. The page you are on expands its parent group and subgroup, so you always know where you are.
Group and subgroup collapse states persist in localStorage under 86d-admin-sidebar-collapsed, so your sidebar survives reloads and browser restarts.

​
Merchant UI contract

Store Admin follows the same merchant interaction contract as 86d Console: shared OKLCH tokens (copied into public-owned CSS), Zod + TanStack Form for multi-field forms, TanStack Table for record lists, and Empty / Loading / Error / Permission denied / Provider unavailable states on every screen. The locked reference surfaces are /admin/products and /admin/products/new. The workspace Experience product context holds the full checklist; capability pages stay Experimental until evidence advances.

​
Uploading files

Product images, blog media, and other assets go through one endpoint:
Every file is validated against its magic bytes, so renaming a script to .png does not get it past the door. SVG files are additionally scanned for embedded scripts, event handlers, and javascript: URIs before they are accepted.
Upload and delete are both admin-only, and delete checks Store isolation, so one Store cannot remove another Store’s files. Unauthenticated requests are rejected outright.

​
Admin API limits

Admin endpoints under /api/admin/... allow 300 requests per minute per signed-in user. That is higher than the public limit because a merchant clicking through screens is not a scraper. Going over returns HTTP 429 with Retry-After and X-RateLimit-Reset headers, and this body:
Every admin error uses that same { error: { code, message } } envelope. If you are writing an agent against Store Admin, branch on error.code, not on the message text.

​
Getting oriented

1

Sign in

Go to /admin. If you are not authenticated you land on /auth/signin.
2

Read the overview

The home screen pulls stat cards from /api/admin/products and /api/admin/categories, so it shows what your enabled Modules actually know.
3

Find a Module's pages

Use the two-level sidebar. Expand a group, then pick a subgroup or page.
4

Manage Products

Under Catalog, the Products section handles search, status filtering, pagination, create, edit, and delete. Slugs generate themselves.
On a phone the sidebar collapses into a menu with the same two-level structure. Nothing is hidden on mobile that is available on desktop.