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, search
  • products/resolve, products/variants/resolve, products/[id]/options
  • pricing/quote
  • auth/request-otp, auth/verify-otp, auth/complete-profile, auth/logout
  • account/me, account/orders
  • checkout, orders
  • storefronts/resolve, pages*, blogs*, product-lists*

Customer auth flow

  1. POST /api/storefront/auth/request-otp: creates OTP and sends email.
  2. POST /api/storefront/auth/verify-otp: verifies code and sets wb_customer_session cookie.
    • returns needsProfile=true for new email without counterparty
  3. POST /api/storefront/auth/complete-profile: finalizes customer profile for pending sessions.
  4. POST /api/storefront/auth/logout: clears storefront cookie.

Session kinds:

  • pending_profile
  • customer

Product data source behavior

Storefront product/catalog resolution uses these switches:

  • USE_LOCAL_PRODUCTS=true: local DB source
  • otherwise, if module moysklad is 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.