Storefront
Practical workflow for creating and maintaining storefront repos.
This page documents the storefront API behavior implemented inside Workbase.
Endpoint groups
Key storefront route groups under /api/storefront/*:
catalog,categories,searchproducts/resolve,products/variants/resolve,products/[id]/optionspricing/quoteauth/request-otp,auth/verify-otp,auth/complete-profile,auth/logoutaccount/me,account/orderscheckout,ordersstorefronts/resolve,pages*,blogs*,product-lists*
Customer auth flow
POST /api/storefront/auth/request-otp: creates OTP and sends email.POST /api/storefront/auth/verify-otp: verifies code and setswb_customer_sessioncookie.- returns
needsProfile=truefor new email without counterparty
- returns
POST /api/storefront/auth/complete-profile: finalizes customer profile for pending sessions.POST /api/storefront/auth/logout: clears storefront cookie.
Session kinds:
pending_profilecustomer
Product data source behavior
Storefront product/catalog resolution uses these switches:
USE_LOCAL_PRODUCTS=true: local DB source- otherwise, if module
moyskladis enabled for company: MoySklad source - otherwise: local fallback (if local data exists)
Category APIs also support local-mode toggling with USE_LOCAL_CATEGORIES.
CORS behavior
Storefront routes use permissive CORS helper (Access-Control-Allow-Origin: *) via applyStorefrontCors().
Checkout integration
/api/storefront/checkout submits customer orders to MoySklad (/entity/customerorder) and resolves/creates counterparties as needed.
Operational notes
- Storefront company context is resolved from authenticated actor in
resolveStorefrontCompanyId(). - Missing company assignment results in
403. - OTP flows enforce both IP and per-email rate limits.