FURAZHIR / product reference

Panel, server routes, and delivery — without a black box.

A verifiable catalog of the technical surface: Studio capabilities, stable API v1, internal routes, SDK, integrations, operational topology, and delivery options.

Checked against the manifest and source · 2026-08-09

furazhir.reference.json

01platformincluded

02public_apiv1

03openapi3.1

04deploymentsingle_tenant

05delivery_modelby_contract

source-aligned reference
94
panel capabilities
54
server routes
39
command contracts
single-tenant deployment
01 / PACKAGE

What is connected in one delivery.

The UI, server logic, and background processes share domain contracts. This is not a set of screens or a shared SaaS: every buyer runs an isolated installation.

01Studio

Operations panel

Catalog, orders, requests, reviews, content, email, analytics, audit, and sessions.

02Gateway

API and integrations

Versioned /api/v1, OpenAPI 3.1, API keys, scopes, and a TypeScript SDK.

03Runtime

Background processing

Worker, outbox, retries, retention, health/readiness, and operational probes.

04Delivery

Delivery package

Source archive or image, migrations, Compose, runbooks, SDK, SBOM, and release documents as agreed in the contract.

02 / COMPLETE INVENTORY

Find a capability.
Verify its contract.

Included means the capability ships in the self-hosted platform. Demo status means the same flow is available with synthetic data; the demo does not accept real data or money.

94 features · 54 routes
01

Panel capabilities

94
01Access, navigation and edit safetyTOTP access, localization, themes, responsive behavior, loading states, and unsaved-change protection.7 features
  1. ACC-SHL-001

    Studio navigation and workspace summaries

    includedin demo
    Purpose
    “Studio navigation and workspace summaries” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Desktop navigation · Mobile drawer · Per-section counts
    What changes
    activeSection · sectionSummaries
    Contract
    GET workspace snapshot
    How to verify it
    • All nine platform sections remain reachable and report counts from persisted state.
    Demo boundary
    Only synthetic workspace summaries are shown.
    Open the practical handbook walkthrough
  2. ACC-SHL-002

    Dark and light theme

    includedin demo
    Purpose
    “Dark and light theme” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Theme toggle
    What changes
    browser theme preference
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Both themes retain contrast, focus, reduced-motion and forced-colors behavior.
    Demo boundary
    Theme state remains local to the browser.
    Open the practical handbook walkthrough
  3. ACC-SHL-003

    Six-locale localization

    includedin demo
    Purpose
    “Six-locale localization” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Locale switcher · Localized dates, numbers and labels
    What changes
    locale
    Contract
    Localized errors and CSV headings
    How to verify it
    • Every Studio label, error, audit value and export heading switches without reload loss.
    Demo boundary
    Locale changes never alter identity or authorization.
    Open the practical handbook walkthrough
  4. ACC-SHL-004

    Workspace load, refresh and retry

    includedin demo
    Purpose
    “Workspace load, refresh and retry” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Loading · Load error · Retry · Refresh
    What changes
    workspace load state · request id · latency
    Contract
    GET /api/admin/catalog, /api/admin/content and /api/admin/operations
    How to verify it
    • Retry and refresh recover without discarding a dirty draft silently.
    Demo boundary
    No cached cross-session snapshot is rendered.
    Open the practical handbook walkthrough
  5. ACC-SHL-005

    Dirty-state counters and discard protection

    includedin demo
    Purpose
    “Dirty-state counters and discard protection” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Dirty badges · Save all · Discard dialog · beforeunload guard
    What changes
    draft baselines · dirty record ids
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Navigation, refresh and exit require confirmation whenever an unsaved draft exists.
    Demo boundary
    The guard is browser-local and reveals no persisted data.
    Open the practical handbook walkthrough
  6. ACC-SHL-006

    Token plus TOTP access

    includedin demo
    Purpose
    “Token plus TOTP access” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Demo access screen · Token and one-time-code walkthrough
    What changes
    sandbox access challenge · demo operator session
    Contract
    POST /api/admin/session · DELETE /api/admin/session
    How to verify it
    • The walkthrough creates an isolated admin session and rate-limits failed attempts.
    Demo boundary
    The complete token plus one-time-code flow uses disclosed synthetic sandbox credentials. Production keeps the same flow but requires a private per-installation TOTP secret; the hosted demo never requests or accepts it.
    Open the practical handbook walkthrough
  7. ACC-SHL-007

    Responsive and accessible interaction system

    includedin demo
    Purpose
    “Responsive and accessible interaction system” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
    Interface
    Focus trap · Focus restore · Keyboard operation · Accessible confirmations
    What changes
    dialog and drawer state
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • All dialogs and bulk confirmations work by keyboard at phone and desktop widths.
    Demo boundary
    UI state is ephemeral.
    Open the practical handbook walkthrough
02Catalog, SKUs and fulfillmentSix work modes, product cards, variants, the SKU matrix, inventory, categories, attributes, and CSV exports.17 features
  1. ACC-CAT-001

    Six catalog work modes

    includedin demo
    Purpose
    “Six catalog work modes” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    operations · simple · card · categories · pickup · filters
    What changes
    catalog view
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • The six modes share filters, selection and persisted mutations without duplicate mock state.
    Demo boundary
    All modes operate only on the current synthetic workspace.
    Open the practical handbook walkthrough
  2. ACC-CAT-002

    Server catalog filters, facets and pagination

    includedin demo
    Purpose
    “Server catalog filters, facets and pagination” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Search · Status filter · Category filter · Brand filter · Load more
    What changes
    catalog cursor · status/category/brand/query filters · facets
    Contract
    GET /api/admin/catalog/products
    How to verify it
    • Facets and totals remain correct after mutations and cursor pages contain no duplicates.
    Demo boundary
    Query length, page size and scan work are bounded.
    Open the practical handbook walkthrough
  3. ACC-CAT-003

    Product CRUD and lifecycle status

    includedin demo
    Purpose
    “Product CRUD and lifecycle status” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Create · Edit · Delete · Active/draft/archive
    What changes
    products
    Contract
    catalog.product.create · catalog.product.update · catalog.product.delete · POST/PATCH/DELETE /api/admin/catalog
    How to verify it
    • Create, edit, status and delete survive reload and emit typed audit events.
    Demo boundary
    Capacity and string limits prevent unbounded workspace growth.
    Open the practical handbook walkthrough
  4. ACC-CAT-004

    Complete product identity and merchandising fields

    includedin demo
    Purpose
    “Complete product identity and merchandising fields” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Full product card
    What changes
    categoryId · brandId · brand · name · description · priceValue · href · status · defaultVariantId
    Contract
    catalog.product.create · catalog.product.update · GET /api/admin/catalog/products/:id
    How to verify it
    • Every platform product field round-trips and is represented in public catalog projection where appropriate.
    Demo boundary
    Links are validated as relative or allow-listed demo URLs.
    Open the practical handbook walkthrough
  5. ACC-CAT-005

    Product and catalog translations

    includedin demo
    Purpose
    “Product and catalog translations” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    RU/EN/FR/ZH-CN/DE/ES translation editors
    What changes
    product translations · category translations · attribute translations · option translations · filter translations
    Contract
    catalog.product.update · catalog.category.upsert · catalog.filters.batch-update · Localized catalog projection
    How to verify it
    • Locale selection changes catalog labels without mutating canonical identifiers.
    Demo boundary
    Text-only translated values are length bounded.
    Open the practical handbook walkthrough
  6. ACC-CAT-006

    Product and variant images

    includedin demo
    Purpose
    “Product and variant images” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Upload controls · Preview · Alt text · Gallery editor
    What changes
    uploads · product image · product gallery · variant image · variant gallery
    Contract
    upload.create · upload.delete · catalog.product.update · catalog.variant.update · POST/GET/DELETE /api/admin/uploads
    How to verify it
    • An uploaded image is visible only to its session, can be assigned, removed and is deleted on reset or expiry.
    Demo boundary
    Session-owned R2 objects, magic-byte validation, SVG denial, byte quotas and TTL cleanup are mandatory.
    Open the practical handbook walkthrough
  7. ACC-CAT-007

    Shared product labels and legacy swatches

    includedin demo
    Purpose
    “Shared product labels and legacy swatches” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Shared label picker · Create label · Swatch editor
    What changes
    productLabels · product label reference · swatches
    Contract
    catalog.label.create · catalog.product.update · POST /api/admin/catalog
    How to verify it
    • A shared label can be created once, reused and audited; valid swatches persist.
    Demo boundary
    Labels and colors are bounded synthetic metadata.
    Open the practical handbook walkthrough
  8. ACC-CAT-008

    Variant and SKU CRUD

    includedin demo
    Purpose
    “Variant and SKU CRUD” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Add · Duplicate · Remove · Quick edit · Default variant
    What changes
    variants · SKU · price · stock · reserved · status
    Contract
    catalog.variant.create · catalog.variant.update · catalog.variant.delete · catalog.variant.batch-update · PATCH /api/admin/catalog
    How to verify it
    • SKU identity is case-insensitively unique and stock can never fall below reserved quantity.
    Demo boundary
    Variant count, SKU length and numeric ranges are bounded.
    Open the practical handbook walkthrough
  9. ACC-CAT-009

    Universal SKU matrix

    includedin demo
    Purpose
    “Universal SKU matrix” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Axis selection · Matrix rebuild · Bulk price/stock/status · Matrix paging
    What changes
    variant axes · selected option combinations · matrix drafts
    Contract
    catalog.variant.batch-update · PATCH /api/admin/catalog
    How to verify it
    • Matrix rebuild produces each selected canonical combination exactly once and preserves compatible edits.
    Demo boundary
    Combination count and variants per product are capped.
    Open the practical handbook walkthrough
  10. ACC-CAT-010

    Product-level universal attributes

    includedin demo
    Purpose
    “Product-level universal attributes” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Typed product attribute editor
    What changes
    product attribute values · immutable order snapshots
    Contract
    catalog.product.update · Catalog and order projections
    How to verify it
    • Required and typed attributes validate and category changes retain only compatible values.
    Demo boundary
    Values are validated against the current category schema.
    Open the practical handbook walkthrough
  11. ACC-CAT-011

    Catalog validation and edit readiness

    includedin demo
    Purpose
    “Catalog validation and edit readiness” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Inline errors · Readiness summary · Guided empty state
    What changes
    validation issues · dirty baselines
    Contract
    Structured validation errors
    How to verify it
    • Client and server reject the same duplicate SKU, invalid schema, price, stock and reserve cases.
    Demo boundary
    Invalid records never reach persisted state.
    Open the practical handbook walkthrough
  12. ACC-CAT-012

    Category CRUD and ordering

    includedin demo
    Purpose
    “Category CRUD and ordering” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Category manager
    What changes
    categories · product counts
    Contract
    catalog.category.upsert · catalog.category.delete · PATCH /api/admin/catalog
    How to verify it
    • ID, label, title, description, status and position persist and counts remain correct.
    Demo boundary
    Deletion is blocked when referential rules would be violated.
    Open the practical handbook walkthrough
  13. ACC-CAT-013

    Category attribute schemas and option libraries

    includedin demo
    Purpose
    “Category attribute schemas and option libraries” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Attribute and option schema editor
    What changes
    schema revision/status · attribute definitions · attribute options
    Contract
    catalog.category.upsert · Catalog metadata projection
    How to verify it
    • All scope, type, display, unit, help, required, filterable, searchable, comparable, option and translation constraints match platform validation.
    Demo boundary
    Attribute and option counts, identifiers and color values are capped and validated.
    Open the practical handbook walkthrough
  14. ACC-CAT-014

    Storefront filter configuration

    includedin demo
    Purpose
    “Storefront filter configuration” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Filter label/status/order/translation editor
    What changes
    filterSettings
    Contract
    catalog.filters.batch-update · PATCH /api/admin/catalog
    How to verify it
    • Search, brand, price, availability and sort settings update atomically and affect public catalog metadata.
    Demo boundary
    Only the five supported filter identifiers are accepted.
    Open the practical handbook walkthrough
  15. ACC-CAT-015

    Pickup locations, time slots and courier delivery

    includedin demo
    Purpose
    “Pickup locations, time slots and courier delivery” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Pickup manager · Time-slot editor · Courier toggle
    What changes
    pickupLocations · timeSlots · courierDeliveryEnabled
    Contract
    catalog.pickup.upsert · catalog.pickup.delete · catalog.fulfillment.update · PATCH /api/admin/catalog
    How to verify it
    • Location and time-slot CRUD, status and ordering immediately affect order and storefront projections.
    Demo boundary
    Addresses are synthetic and no logistics provider is contacted.
    Open the practical handbook walkthrough
  16. ACC-CAT-016

    Atomic catalog batch save

    includedin demo
    Purpose
    “Atomic catalog batch save” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Save all · Dirty count
    What changes
    product and variant draft set
    Contract
    catalog.product.batch-update · catalog.variant.batch-update · PATCH /api/admin/catalog
    How to verify it
    • Either all validated patches commit under the expected revision or none do.
    Demo boundary
    Batch length and serialized state size are bounded.
    Open the practical handbook walkthrough
  17. ACC-CAT-017

    Server stock export

    includedin demo
    Purpose
    “Server stock export” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
    Interface
    Stock CSV download
    What changes
    products · variants
    Contract
    POST /api/admin/catalog/export
    How to verify it
    • CSV includes complete SKU stock/reserve/status rows and returns count/truncation headers.
    Demo boundary
    Export is synthetic, rate-limited, size-capped and audited.
    Open the practical handbook walkthrough
03Orders and fulfillment operationsReservation-aware statuses, search, archive, priorities, bulk actions, exports, and idempotent creation.10 features
  1. ACC-ORD-001

    Active and archived order flows

    includedin demo
    Purpose
    “Active and archived order flows” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Active flow · Archive flow · Restore
    What changes
    orders · archivedAt
    Contract
    order.archive-batch · GET/PATCH /api/admin/operations
    How to verify it
    • Archive and restore preserve the record and remove it from the opposite flow immediately.
    Demo boundary
    Only synthetic orders are changed.
    Open the practical handbook walkthrough
  2. ACC-ORD-002

    Server order search, filters and cursor history

    includedin demo
    Purpose
    “Server order search, filters and cursor history” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Query · Flow · Status · Load more
    What changes
    order filters · history cursor
    Contract
    GET /api/admin/operations/history?resource=orders
    How to verify it
    • Stable cursor pages honor flow, status and query without duplicates.
    Demo boundary
    Query and page sizes are bounded.
    Open the practical handbook walkthrough
  3. ACC-ORD-003

    Inventory-aware order status transitions

    includedin demo
    Purpose
    “Inventory-aware order status transitions” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Contextual transition actions
    What changes
    new · processing · completed · delivered · cancelled
    Contract
    order.update · order.batch-update · PATCH /api/admin/operations
    How to verify it
    • The exact platform enum is accepted; new/processing reserve units, completed/delivered deduct stock and release reserve, cancelled releases reserve, and every inverse transition restores the corresponding inventory effect.
    Demo boundary
    A status change is atomic and fails with a structured conflict when its stock/reserve effect would violate an inventory invariant.
    Open the practical handbook walkthrough
  4. ACC-ORD-004

    Priority, deadline and support notes

    includedin demo
    Purpose
    “Priority, deadline and support notes” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Priority · Planned date · Internal note · Customer message · Overdue warning
    What changes
    priority normal/urgent/hold · fulfillmentDeadline · adminNote · customerNote
    Contract
    order.update · PATCH /api/admin/operations
    How to verify it
    • All four support fields save together and overdue state derives from the deadline.
    Demo boundary
    Notes are synthetic text with strict lengths.
    Open the practical handbook walkthrough
  5. ACC-ORD-005

    Complete customer and fulfillment details

    includedin demo
    Purpose
    “Complete customer and fulfillment details” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Order detail card
    What changes
    customer email/profile notes/contact method/messenger · delivery/pickup/address details/time slot/comment/payment
    Contract
    GET /api/admin/operations
    How to verify it
    • Every optional detail renders conditionally with the same labels and fallback rules as platform.
    Demo boundary
    Seeded contacts use reserved example domains and fictitious addresses.
    Open the practical handbook walkthrough
  6. ACC-ORD-006

    Order items and immutable attribute snapshots

    includedin demo
    Purpose
    “Order items and immutable attribute snapshots” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Line-item list
    What changes
    order items · variant id · quantity · price · attribute snapshots
    Contract
    Order response
    How to verify it
    • Changing a product schema after order creation does not change the order's displayed item attributes.
    Demo boundary
    Order snapshots contain only synthetic catalog data.
    Open the practical handbook walkthrough
  7. ACC-ORD-007

    Order summary and risk indicators

    includedin demo
    Purpose
    “Order summary and risk indicators” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Command statistics · Urgent and overdue highlights
    What changes
    status/priority/deadline counts · visible revenue
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Counts and revenue recalculate after every visible mutation.
    Demo boundary
    Metrics are derived, not separately persisted.
    Open the practical handbook walkthrough
  8. ACC-ORD-008

    Bulk order operations

    includedin demo
    Purpose
    “Bulk order operations” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    Select shown · Limit 500 · Bulk status/archive/restore · Confirmation dialog
    What changes
    selected order ids
    Contract
    order.batch-update · order.archive-batch · PATCH /api/admin/operations
    How to verify it
    • Bulk updates are atomic, affect only selected IDs and add a bounded audit payload.
    Demo boundary
    Selection and body sizes are bounded; confirmation names the impact.
    Open the practical handbook walkthrough
  9. ACC-ORD-009

    Server-filtered order export

    includedin demo
    Purpose
    “Server-filtered order export” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    CSV export
    What changes
    current order filters
    Contract
    POST /api/admin/operations/export
    How to verify it
    • Export applies the same flow, status and query as the visible list and records an audit event.
    Demo boundary
    Rate-limited export includes synthetic rows only.
    Open the practical handbook walkthrough
  10. ACC-ORD-010

    Idempotent API order creation and reservation

    includedin demo
    Purpose
    “Idempotent API order creation and reservation” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab order example
    What changes
    idempotency record · order · variant reserve
    Contract
    POST /api/demo/v1/orders
    How to verify it
    • A repeated key and identical body replays; a conflicting body fails; successful creation updates orders, stock reserve and audit.
    Demo boundary
    Only session-owned synthetic orders are created; no payment or notification leaves the sandbox.
    Open the practical handbook walkthrough
04Subscriptions and customer requestsDouble opt-in, unsubscribe, request triage, bulk statuses, outbox-backed replies, and exports.8 features
  1. ACC-COM-001

    Newsletter subscription records

    includedin demo
    Purpose
    “Newsletter subscription records” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Subscription list and detail
    What changes
    contact identity · source · status · consent and confirmation timestamps
    Contract
    contact.update · GET/PATCH /api/admin/operations
    How to verify it
    • Pending, confirmed and unsubscribed states preserve consent and lifecycle metadata.
    Demo boundary
    All addresses use reserved example domains.
    Open the practical handbook walkthrough
  2. ACC-COM-002

    Feedback request records

    includedin demo
    Purpose
    “Feedback request records” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Feedback list and detail
    What changes
    name · email · contact · contact method · messenger · message · source · customer key
    Contract
    contact.update · GET/PATCH /api/admin/operations
    How to verify it
    • Every platform contact field renders and can be searched without mixing newsletter rows.
    Demo boundary
    The public demo warns against real personal data and stores bounded synthetic values.
    Open the practical handbook walkthrough
  3. ACC-COM-003

    Contact search, filters and cursor history

    includedin demo
    Purpose
    “Contact search, filters and cursor history” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Search · Status · Load more
    What changes
    section/status/query filters · history cursor
    Contract
    GET /api/admin/operations/history?resource=contactRequests
    How to verify it
    • Newsletter and feedback history pages remain separate and stable under concurrent status updates.
    Demo boundary
    Query and page sizes are bounded.
    Open the practical handbook walkthrough
  4. ACC-COM-004

    Single and bulk contact status actions

    includedin demo
    Purpose
    “Single and bulk contact status actions” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Select shown · Take in work · Return to new · Archive/unsubscribe
    What changes
    selected contact ids · contact status
    Contract
    contact.update · contact.batch-update · PATCH /api/admin/operations
    How to verify it
    • Bulk transitions are atomic and newsletter unsubscribe cannot be presented as feedback archive.
    Demo boundary
    Bulk selection is capped at 500.
    Open the practical handbook walkthrough
  5. ACC-COM-005

    Confirmed subscribers and feedback CSV exports

    includedin demo
    Purpose
    “Confirmed subscribers and feedback CSV exports” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Export confirmed · Export feedback
    What changes
    current contact filters
    Contract
    POST /api/admin/operations/export
    How to verify it
    • Newsletter export includes confirmed recipients only; feedback export honors current filters.
    Demo boundary
    Exports are rate-limited and contain reserved-domain addresses only.
    Open the practical handbook walkthrough
  6. ACC-COM-006

    Idempotent feedback reply

    includedin demo
    Purpose
    “Idempotent feedback reply” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Subject · Message · Queue feedback
    What changes
    reply subject · reply body · idempotency record · outbox item
    Contract
    contact.reply · POST /api/admin/operations
    How to verify it
    • A replay returns the same outbox item and does not duplicate it; successful reply marks the request processed.
    Demo boundary
    Reply is rendered and queued internally but never delivered externally.
    Open the practical handbook walkthrough
  7. ACC-COM-007

    Double opt-in and unsubscribe effects

    includedin demo
    Purpose
    “Double opt-in and unsubscribe effects” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Lifecycle metadata · Sandbox confirmation action
    What changes
    confirmation expiry · confirmedAt · unsubscribedAt
    Contract
    POST /api/demo/newsletter · POST /api/demo/newsletter/one-click
    How to verify it
    • Confirmation is single-use and unsubscribe immediately excludes the record from future campaign snapshots.
    Demo boundary
    Signed links are session-bound and never address real recipients.
    Open the practical handbook walkthrough
  8. ACC-COM-008

    Durable reply outbox state

    includedin demo
    Purpose
    “Durable reply outbox state” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
    Interface
    Outbox history
    What changes
    pending/sent/failed/skipped · attempt count · next attempt · error · sentAt
    Contract
    contact.reply · GET /api/admin/operations/history?resource=emailOutbox
    How to verify it
    • The reply outbox survives reload, exposes attempt metadata and is cursor-paginated.
    Demo boundary
    Terminal sandbox state is `skipped` or `sandboxed`; no SMTP connection exists.
    Open the practical handbook walkthrough
05Reviews and moderationHome and product reviews, order linking, images, readiness checks, and bulk moderation.7 features
  1. ACC-REV-001

    Home and product review types

    includedin demo
    Purpose
    “Home and product review types” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Review type switch
    What changes
    reviewType home/product
    Contract
    review.create · review.update · GET /api/admin/operations
    How to verify it
    • Type filters and create forms preserve independent home and product workflows.
    Demo boundary
    All review authors and products are synthetic.
    Open the practical handbook walkthrough
  2. ACC-REV-002

    Review search, status filters and cursor history

    includedin demo
    Purpose
    “Review search, status filters and cursor history” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Search · Type · Status · Load more
    What changes
    type/status/query filters · history cursor
    Contract
    GET /api/admin/operations/history?resource=reviews
    How to verify it
    • History is stable and totals reflect all matching synthetic reviews.
    Demo boundary
    Query and page sizes are bounded.
    Open the practical handbook walkthrough
  3. ACC-REV-003

    Review create, edit and delete

    includedin demo
    Purpose
    “Review create, edit and delete” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Create mode · Moderation editor · Delete confirmation
    What changes
    full review record
    Contract
    review.create · review.update · review.delete · POST/PATCH/DELETE /api/admin/operations
    How to verify it
    • ID, author, role, rating, body, status and position round-trip and audit correctly.
    Demo boundary
    Review capacity and text length are bounded.
    Open the practical handbook walkthrough
  4. ACC-REV-004

    Delivered-order product linking

    includedin demo
    Purpose
    “Delivered-order product linking” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Order source and product selectors
    What changes
    delivered product targets · orderId · productId · productName
    Contract
    review.create · review.update · Operations snapshot
    How to verify it
    • A product review can select a delivered item and receives its stable product identity.
    Demo boundary
    Only seeded delivered orders may be linked.
    Open the practical handbook walkthrough
  5. ACC-REV-005

    Review image and preview

    includedin demo
    Purpose
    “Review image and preview” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Image URL · Upload · Alt text · Preview
    What changes
    imageSrc · imageAlt · upload ownership
    Contract
    upload.create · upload.delete · review.update · POST/GET/DELETE /api/admin/uploads
    How to verify it
    • A session-owned image can be previewed, saved and cleaned when no longer referenced.
    Demo boundary
    The catalog upload security policy is reused.
    Open the practical handbook walkthrough
  6. ACC-REV-006

    Review readiness and summary metrics

    includedin demo
    Purpose
    “Review readiness and summary metrics” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Readiness pills · Character count · Summary cards
    What changes
    quality result · status/type/photo/rating counts
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Readiness and all summary counts update as drafts and saved reviews change.
    Demo boundary
    Metrics are derived from current state.
    Open the practical handbook walkthrough
  7. ACC-REV-007

    Moderation and bulk review actions

    includedin demo
    Purpose
    “Moderation and bulk review actions” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
    Interface
    Publish · Hide · Select shown · Save all
    What changes
    selected review ids · review drafts
    Contract
    review.update · review.batch-update · PATCH /api/admin/operations
    How to verify it
    • Single and bulk status changes use the same exact validation and atomic persistence.
    Demo boundary
    Bulk selection and audit payload are bounded.
    Open the practical handbook walkthrough
06Content and marketing placementsStructured text, placements, CTAs, media, batch saves, and published-only delivery.8 features
  1. ACC-CNT-001

    Public content groups and scopes

    includedin demo
    Purpose
    “Public content groups and scopes” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Content group navigation
    What changes
    home · marketing · catalog · product · cart · footer · legal · consent
    Contract
    content.entry.create · content.entry.update · GET /api/admin/content
    How to verify it
    • Exact platform groups and scopes control filtering and public placement.
    Demo boundary
    The internal Studio scope remains hidden from public projections.
    Open the practical handbook walkthrough
  2. ACC-CNT-002

    Content search and filters

    includedin demo
    Purpose
    “Content search and filters” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Search · Group/scope · Status · Reset
    What changes
    query · scope · status
    Contract
    GET /api/admin/content
    How to verify it
    • Counts and visible text/marketing rows honor all active filters.
    Demo boundary
    Search length is bounded.
    Open the practical handbook walkthrough
  3. ACC-CNT-003

    Text entry CRUD and positioning

    includedin demo
    Purpose
    “Text entry CRUD and positioning” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Composer · Inline editor · Advanced ID · Delete
    What changes
    id · scope · title · body · status · position
    Contract
    content.entry.create · content.entry.update · content.entry.delete · POST/PATCH/DELETE /api/admin/content
    How to verify it
    • All fields round-trip, order by position and publish state projects correctly.
    Demo boundary
    Text is length-bounded and always rendered as escaped plain text; operator input is never interpreted as HTML.
    Open the practical handbook walkthrough
  4. ACC-CNT-004

    Atomic text batch save and dirty overview

    includedin demo
    Purpose
    “Atomic text batch save and dirty overview” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Dirty count · Save texts · Content quality overview
    What changes
    content drafts and baselines · quality overview
    Contract
    content.entry.batch-update · PATCH /api/admin/content
    How to verify it
    • Valid text patches commit atomically and dirty state clears only after server success.
    Demo boundary
    Batch size and total state bytes are bounded.
    Open the practical handbook walkthrough
  5. ACC-CNT-005

    Marketing block CRUD

    includedin demo
    Purpose
    “Marketing block CRUD” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Marketing editor · Delete · Placement preview
    What changes
    marketingBlocks
    Contract
    marketing.block.create · marketing.block.update · marketing.block.delete · POST/PATCH/DELETE /api/admin/content
    How to verify it
    • Marketing blocks create, update, delete and render in their target preview.
    Demo boundary
    CTA URLs are relative or allow-listed; media obeys upload policy.
    Open the practical handbook walkthrough
  6. ACC-CNT-006

    Marketing placement, variant, layout and CTA fields

    includedin demo
    Purpose
    “Marketing placement, variant, layout and CTA fields” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Complete marketing editor
    What changes
    home-promotion/cart-advertising · text/image/mixed · fixed/content · title/text/image/alt/href/CTA/status/position
    Contract
    marketing.block.create · marketing.block.update · Public marketing projection
    How to verify it
    • All exact enums and fields validate and public projection excludes non-published blocks.
    Demo boundary
    No scriptable markup or arbitrary external asset fetch is allowed.
    Open the practical handbook walkthrough
  7. ACC-CNT-007

    Marketing batch save and media upload

    includedin demo
    Purpose
    “Marketing batch save and media upload” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    Save marketing · Upload and preview
    What changes
    marketing drafts · upload ownership · durable orphan cleanup queue
    Contract
    marketing.block.batch-update · upload.create · upload.delete · PATCH /api/admin/content · POST/DELETE /api/admin/uploads
    How to verify it
    • Batch save is atomic and replacing media schedules the previous unreferenced object for cleanup.
    Demo boundary
    R2 ownership, byte quotas and cleanup apply.
    Open the practical handbook walkthrough
  8. ACC-CNT-008

    Published-only public content projection

    includedin demo
    Purpose
    “Published-only public content projection” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab content response
    What changes
    content and marketing status
    Contract
    GET /api/demo/v1/content
    How to verify it
    • Public content returns published text and marketing only and supports scope filtering.
    Demo boundary
    Draft and archived values never leave the admin projection.
    Open the practical handbook walkthrough
07Email campaigns and outboxSMTP diagnostics, audiences, safe previews, idempotent enqueue, worker processing, and attempt history.12 features
  1. ACC-EML-001

    Email configuration diagnostics

    includedin demo
    Purpose
    “Email configuration diagnostics” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Four diagnostics cards
    What changes
    notifications/configuration/from/admin recipient/HELO/TLS state
    Contract
    GET operations snapshot
    How to verify it
    • Diagnostics explain why campaign enqueue is enabled or disabled without exposing secrets.
    Demo boundary
    Only normalized sandbox configuration is exposed; no credentials or raw transport errors.
    Open the practical handbook walkthrough
  2. ACC-EML-002

    Safe transport verification

    includedin demo
    Purpose
    “Safe transport verification” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Verify/check again
    What changes
    verification status/timestamps/failure code
    Contract
    email.transport.verify · POST /api/admin/email-diagnostics
    How to verify it
    • The rate-limited action persists a normalized result and invalidates it when sandbox configuration changes.
    Demo boundary
    Verification checks an internal deterministic sandbox transport and never opens SMTP.
    Open the practical handbook walkthrough
  3. ACC-EML-003

    Subscriber and customer audience search

    includedin demo
    Purpose
    “Subscriber and customer audience search” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Audience switch · Search · Pagination
    What changes
    audience · recipient search · recipient page
    Contract
    GET /api/admin/email-campaigns
    How to verify it
    • Search totals and pages are stable for subscribers and customers separately.
    Demo boundary
    Only confirmed synthetic recipients are returned.
    Open the practical handbook walkthrough
  4. ACC-EML-004

    Selected or all-recipient campaign mode

    includedin demo
    Purpose
    “Selected or all-recipient campaign mode” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Selected · All found · Select visible · 500 selection limit
    What changes
    selection mode · selected ids · audience snapshot
    Contract
    email.campaign.enqueue · POST /api/admin/email-campaigns
    How to verify it
    • Selected mode preserves exact IDs; all mode snapshots the matching audience at enqueue time.
    Demo boundary
    Recipient IDs are session-owned and addresses never leave the sandbox.
    Open the practical handbook walkthrough
  5. ACC-EML-005

    Complete campaign composer

    includedin demo
    Purpose
    “Complete campaign composer” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Composer fields · CTA toggle · Image toggle/upload
    What changes
    subject · preheader · title · body · CTA · image
    Contract
    email.campaign.preview · email.campaign.enqueue · POST /api/admin/email-campaigns
    How to verify it
    • Exact platform field limits and conditional CTA/image requirements are enforced client and server-side.
    Demo boundary
    Operator HTML is rejected and every field is escaped server-side.
    Open the practical handbook walkthrough
  6. ACC-EML-006

    Server-rendered email preview

    includedin demo
    Purpose
    “Server-rendered email preview” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Desktop/mobile preview · Placeholder and readiness state
    What changes
    preview html/text · sendReady · placeholder fields · draft fingerprint
    Contract
    email.campaign.preview · POST /api/admin/email-campaigns operation=preview
    How to verify it
    • Any content edit makes the old preview stale and enqueue remains disabled until a current send-ready preview exists.
    Demo boundary
    Preview is escaped, sandboxed and has no active links or scripts.
    Open the practical handbook walkthrough
  7. ACC-EML-007

    Explicit audience confirmation

    includedin demo
    Purpose
    “Explicit audience confirmation” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Confirmation checkbox and recipient count
    What changes
    confirmed draft fingerprint
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Changing content, audience or selection clears confirmation before enqueue.
    Demo boundary
    Confirmation is tied to the exact current draft and selection.
    Open the practical handbook walkthrough
  8. ACC-EML-008

    Idempotent campaign enqueue

    includedin demo
    Purpose
    “Idempotent campaign enqueue” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Queue campaign
    What changes
    campaign · idempotency key and request fingerprint
    Contract
    email.campaign.enqueue · POST /api/admin/email-campaigns
    How to verify it
    • A repeated key replays one campaign; conflicting reuse fails without extra outbox rows.
    Demo boundary
    Enqueue creates sandbox records only and performs no external delivery.
    Open the practical handbook walkthrough
  9. ACC-EML-009

    Campaign preparation monitor

    includedin demo
    Purpose
    “Campaign preparation monitor” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Recent campaign cards · Refresh and auto-refresh · Run/retry sandbox queue
    What changes
    preparing/queued/failed/sent/partial · per-campaign recipient progress · attempt/next-at/error retry metadata
    Contract
    GET /api/admin/email-campaigns?mode=status · POST /api/admin/email-campaigns operation=process
    How to verify it
    • Monitor displays persisted failure and retry metadata; retry resolves each campaign with exact independent counters, while a repeated terminal process is a mutation-free no-op.
    Demo boundary
    The first worker pass records a deterministic internal interruption; the visible retry reaches a terminal state without external delivery.
    Open the practical handbook walkthrough
  10. ACC-EML-010

    Durable outbox history and retry presentation

    includedin demo
    Purpose
    “Durable outbox history and retry presentation” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Cursor-paginated delivery history
    What changes
    kind/recipient/subject/status/error/attempt/max/next/sent timestamps
    Contract
    GET /api/admin/operations/history?resource=emailOutbox
    How to verify it
    • Every field and normalized status message matches the platform presentation contract.
    Demo boundary
    Terminal delivery is sandboxed/skipped; SMTP is impossible.
    Open the practical handbook walkthrough
  11. ACC-EML-011

    Unsubscribe exclusion and worker behavior

    includedin demo
    Purpose
    “Unsubscribe exclusion and worker behavior” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Sandbox preparation timeline
    What changes
    audience snapshot · unsubscribe status · per-campaign delivery counters · retry schedule
    Contract
    Campaign status projection · RFC one-click unsubscribe · Sandbox worker process
    How to verify it
    • Recipients unsubscribed before retry become skipped, each campaign reaches an exact terminal state, and one campaign cannot consume another campaign's outbox rows.
    Demo boundary
    The deterministic worker changes only session-owned outbox records and never connects to SMTP.
    Open the practical handbook walkthrough
  12. ACC-EML-012

    Campaign image upload

    includedin demo
    Purpose
    “Campaign image upload” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
    Interface
    Upload · URL · Alt text · Preview
    What changes
    campaign image upload reference
    Contract
    upload.create · upload.delete · POST/DELETE /api/admin/uploads
    How to verify it
    • Preview and campaign reference the same session-owned image and reset deletes it.
    Demo boundary
    R2 ownership, quotas and TTL cleanup apply.
    Open the practical handbook walkthrough
08Sales and inventory analyticsSales metrics and trends, inventory, commercial breakdowns, readiness indicators, and exports.7 features
  1. ACC-ANA-001

    Sales and stock focus switch

    includedin demo
    Purpose
    “Sales and stock focus switch” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Sales/stock switch
    What changes
    analytics focus
    Contract
    The capability uses the section contract without a dedicated public endpoint.
    How to verify it
    • Each focus renders its complete independent metric and chart set.
    Demo boundary
    Focus is browser-local.
    Open the practical handbook walkthrough
  2. ACC-ANA-002

    Derived analytics integrity

    includedin demo
    Purpose
    “Derived analytics integrity” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Live metrics
    What changes
    orders/products/content/reviews/subscriptions
    Contract
    Workspace snapshot
    How to verify it
    • Every relevant mutation changes the affected selector and UI metric without manual synchronization.
    Demo boundary
    Analytics are calculated from current synthetic state and never hard-coded separately.
    Open the practical handbook walkthrough
  3. ACC-ANA-003

    Complete sales metrics

    includedin demo
    Purpose
    “Complete sales metrics” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Nine sales metric cards
    What changes
    revenue/delivered/backlog/cancelled · orders/rates · unit and basket averages
    Contract
    Analytics projection
    How to verify it
    • All platform sales formulas have unit tests and match visible seeded totals.
    Demo boundary
    All money is synthetic RUB data.
    Open the practical handbook walkthrough
  4. ACC-ANA-004

    Sales series and commercial breakdowns

    includedin demo
    Purpose
    “Sales series and commercial breakdowns” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Sales chart and six breakdown panels
    What changes
    dated sales series · order/revenue status · fulfillment/payment · category revenue · top products
    Contract
    Analytics projection
    How to verify it
    • Charts preserve labels, currency/count formatting and usable empty states.
    Demo boundary
    Series are derived from seeded timestamps.
    Open the practical handbook walkthrough
  5. ACC-ANA-005

    Complete stock metrics

    includedin demo
    Purpose
    “Complete stock metrics” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Eight stock metric cards
    What changes
    stock value/available/reserved/share · SKU states · risk value · low/out · publish readiness · review rating
    Contract
    Analytics projection
    How to verify it
    • Stock and variant mutations immediately recalculate all eight metrics.
    Demo boundary
    All values derive from the synthetic catalog.
    Open the practical handbook walkthrough
  6. ACC-ANA-006

    Stock, content, review and subscription breakdowns

    includedin demo
    Purpose
    “Stock, content, review and subscription breakdowns” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Eight stock and readiness panels
    What changes
    category stock/value · variant status · availability/risk · content/review/subscription status
    Contract
    Analytics projection
    How to verify it
    • Every platform breakdown is present, labeled and has a tested empty state.
    Demo boundary
    All breakdowns derive from the same session state.
    Open the practical handbook walkthrough
  7. ACC-ANA-007

    Sales, dynamics and stock exports

    includedin demo
    Purpose
    “Sales, dynamics and stock exports” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
    Interface
    Export orders analytics · Export dynamics · Export stock
    What changes
    analytics snapshot
    Contract
    POST catalog export for stock
    How to verify it
    • Every exported metric equals its visible selector value and uses localized headings.
    Demo boundary
    Exports contain synthetic values and are size-capped.
    Open the practical handbook walkthrough
09Audit and administrative sessionsTyped mutation logs, filters, pagination, session revocation, optimistic concurrency, and limits.8 features
  1. ACC-AUD-001

    Typed audit event for every mutation

    includedin demo
    Purpose
    “Typed audit event for every mutation” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Audit event list
    What changes
    action · entityType · entityId · actor · createdAt
    Contract
    Operations snapshot/history
    How to verify it
    • Every state-changing command emits one typed event on success and none on rejection; read-only campaign preview remains unaudited.
    Demo boundary
    No credentials, raw mail bodies or upload bytes enter audit payloads.
    Open the practical handbook walkthrough
  2. ACC-AUD-002

    Structured bounded audit payload

    includedin demo
    Purpose
    “Structured bounded audit payload” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Localized payload detail
    What changes
    bounded before/after/domain metadata
    Contract
    Audit history
    How to verify it
    • Payload schemaVersion, outcome, entity IDs, changed fields and bounded before/after summaries describe each meaningful successful change; rejected mutations emit no event.
    Demo boundary
    Sensitive and long-content fields are redacted into compact metadata and the serialized demo payload is hard-capped at 8 KiB.
    Open the practical handbook walkthrough
  3. ACC-AUD-003

    Audit query and entity filter

    includedin demo
    Purpose
    “Audit query and entity filter” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Search · Object filter · Reset
    What changes
    query · entity type
    Contract
    GET /api/admin/operations/history?resource=auditEvents
    How to verify it
    • Entity and query filters are server-compatible and totals remain accurate.
    Demo boundary
    Query length is bounded.
    Open the practical handbook walkthrough
  4. ACC-AUD-004

    Audit summary and cursor pagination

    includedin demo
    Purpose
    “Audit summary and cursor pagination” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Four summary cards · Entity insights · Load more
    What changes
    total/entity/latest summaries · history cursor
    Contract
    GET /api/admin/operations/history
    How to verify it
    • Stable pages, totals, truncation state and latest-event card agree after mutations.
    Demo boundary
    History retention and page size are bounded.
    Open the practical handbook walkthrough
  5. ACC-AUD-005

    Administrative session inventory

    includedin demo
    Purpose
    “Administrative session inventory” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Device labels · Current/active badges · Retry
    What changes
    session id/current/actor/IP/user agent/created/seen/expires
    Contract
    GET /api/admin/sessions
    How to verify it
    • The current and seeded other sessions render with stable device and expiry metadata.
    Demo boundary
    IP values are documentation-only synthetic values; the real session token is never returned.
    Open the practical handbook walkthrough
  6. ACC-AUD-006

    Revoke other or all administrative sessions

    includedin demo
    Purpose
    “Revoke other or all administrative sessions” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Revoke others · Revoke all · Danger confirmation
    What changes
    active/revoked session state · independent HttpOnly access marker
    Contract
    session.revoke · PATCH /api/admin/sessions · POST/DELETE /api/admin/session
    How to verify it
    • Others preserves current access; all sets the deny marker; both emit redacted audit events; only the documented demo token plus TOTP restores access.
    Demo boundary
    Revoke all preserves the isolated workspace data but sets an independent HttpOnly deny marker, gates every admin route and redirects /demo to a fixed-credential re-entry screen.
    Open the practical handbook walkthrough
  7. ACC-AUD-007

    Optimistic concurrency and conflict recovery

    includedin demo
    Purpose
    “Optimistic concurrency and conflict recovery” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Conflict notice · Reload and retry
    What changes
    D1 workspace revision · domain drafts
    Contract
    D1 compare-and-swap revision and 409 envelope
    How to verify it
    • A stale write cannot silently overwrite a newer value and the UI preserves the user's draft for retry.
    Demo boundary
    Conflict errors reveal no other session data.
    Open the practical handbook walkthrough
  8. ACC-AUD-008

    Origin, payload, rate and capacity controls

    includedin demo
    Purpose
    “Origin, payload, rate and capacity controls” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
    Interface
    Limit feedback
    What changes
    rate buckets · workspace mutation count · expiry
    Contract
    Exact-origin writes · Strict JSON · 429 and Retry-After
    How to verify it
    • Cross-origin, oversized, malformed and over-budget requests fail before business mutation.
    Demo boundary
    Per-network and per-workspace budgets, TTL and cleanup prevent public abuse.
    Open the practical handbook walkthrough
10Public API v1 and API LabOpenAPI 3.1, scoped API keys, a CORS allow-list, uniform errors, rate limits, and a TypeScript SDK.10 features
  1. ACC-API-001

    Discovery, health and OpenAPI 3.1

    includedin demo
    Purpose
    “Discovery, health and OpenAPI 3.1” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab links
    What changes
    API version and sandbox capability summary
    Contract
    GET /api/demo/v1 · GET /api/demo/v1/health · GET /api/demo/v1/openapi.json
    How to verify it
    • Discovery links every route and OpenAPI exactly matches implemented methods, schemas and security.
    Demo boundary
    Health exposes no internal binding identifiers or migration versions.
    Open the practical handbook walkthrough
  2. ACC-API-002

    Scoped ephemeral API keys

    includedin demo
    Purpose
    “Scoped ephemeral API keys” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab key/scopes · Create/revoke/delete · One-time secret reveal
    What changes
    one-time API key secret · SHA-256 digest · id · scopes · lastUsedAt · revokedAt
    Contract
    Authorization Bearer · X-API-Key
    How to verify it
    • A custom secret is returned once; missing, conflicting, cross-session, revoked and insufficient-scope keys fail closed without revealing key material.
    Demo boundary
    Custom keys are disposable, synthetic, session-bound, revocable and stored only as SHA-256 digests; the bundled tokens are public sandbox credentials with no production authority.
    Open the practical handbook walkthrough
  3. ACC-API-003

    Exact CORS allow-list and preflight

    includedin demo
    Purpose
    “Exact CORS allow-list and preflight” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    CORS example
    What changes
    demo CORS allow-list
    Contract
    OPTIONS and protected v1 responses
    How to verify it
    • Only exact configured HTTPS demo origins receive matching CORS headers and Vary metadata.
    Demo boundary
    No wildcard or credentialed cross-origin access is allowed.
    Open the practical handbook walkthrough
  4. ACC-API-004

    Public catalog query contract

    includedin demo
    Purpose
    “Public catalog query contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    Editable API Lab query
    What changes
    category · repeated brand · search · price min/max · availability · sort · page · attr.*
    Contract
    GET /api/demo/v1/catalog
    How to verify it
    • All platform query parameters validate and return the same catalog semantics and pagination metadata.
    Demo boundary
    Only active synthetic products and available variants are projected.
    Open the practical handbook walkthrough
  5. ACC-API-005

    Public content contract

    includedin demo
    Purpose
    “Public content contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab content request
    What changes
    published content and marketing
    Contract
    GET /api/demo/v1/content?scope=
    How to verify it
    • Response shape and optional scope behavior match platform v1.
    Demo boundary
    Draft, archived and internal content never appears.
    Open the practical handbook walkthrough
  6. ACC-API-006

    Public search contract

    includedin demo
    Purpose
    “Public search contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab search request
    What changes
    public categories and products
    Contract
    GET /api/demo/v1/search?q=&limit=
    How to verify it
    • Response items and q/limit validation match platform v1; admin orders are not leaked.
    Demo boundary
    Search uses public projections only and bounded tokens.
    Open the practical handbook walkthrough
  7. ACC-API-007

    Public idempotent order contract

    includedin demo
    Purpose
    “Public idempotent order contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    Editable API Lab POST
    What changes
    order idempotency and reservation
    Contract
    POST /api/demo/v1/orders · DELETE /api/demo/v1/workspace
    How to verify it
    • The customer order payload, API key scope and Idempotency-Key contract match platform v1; the hosted demo rejects real-like PII and can delete/reset either cookie or header workspaces.
    Demo boundary
    Only clearly synthetic contact data is accepted; no payment, mail, webhook or customer session is touched.
    Open the practical handbook walkthrough
  8. ACC-API-008

    Uniform errors, request and rate headers

    includedin demo
    Purpose
    “Uniform errors, request and rate headers” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    API Lab response metadata
    What changes
    rate bucket
    Contract
    error envelope · X-Request-Id · X-API-Key-Id · X-RateLimit-* · Retry-After
    How to verify it
    • Every protected success and failure response carries the documented stable envelope and headers.
    Demo boundary
    Errors expose no stack, secret, hash or cross-session data.
    Open the practical handbook walkthrough
  9. ACC-API-009

    Real-network API Lab

    includedin demo
    Purpose
    “Real-network API Lab” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    GET resource/query editor · POST order body and Idempotency-Key editor · Bearer/X-API-Key switch · Run · Status/duration/request-id/rate-limit/body · Open created order in Studio
    What changes
    editable query/body/token/idempotency key · live response trace · created order handoff
    Contract
    GET catalog/content/search · POST orders · GET discovery/health/OpenAPI
    How to verify it
    • Lab executes real same-origin requests; the order template comes from live catalog data, POST persists the canonical order, and its handoff opens the Studio Orders section.
    Demo boundary
    Endpoint selection is allow-listed; arbitrary external URLs cannot be requested.
    Open the practical handbook walkthrough
  10. ACC-API-010

    Dependency-free TypeScript SDK examples

    includedin demo
    Purpose
    “Dependency-free TypeScript SDK examples” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
    Interface
    Copyable typed examples
    What changes
    No domain state is mutated; verify a read model or system signal.
    Contract
    Kept aligned with the OpenAPI 3.1 contract and compile-tested
    How to verify it
    • SDK examples compile and exercise catalog, content, search and idempotent order creation.
    Demo boundary
    Examples use the ephemeral demo key and reserved data.
    Open the practical handbook walkthrough
02

Complete server route inventory

54

The inventory lists working methods. OPTIONS and explicit 405 handlers are omitted.

01Stable API v1Versioned external contract with API keys, scopes, OpenAPI, and an SDK.7 routes
  • GET/api/v1Discover the API version, authentication, and resources.
    Purpose
    Discover the API version, authentication, and resources.
    Access and scope
    Public operation: no API key or scope is required.
    Parameters and body
    • No parameters or request body are declared.
    Success response
    200 · Discover the API version, authentication, and resources.
    Errors
    OpenAPI declares no operation-specific error responses for this operation.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
  • GET/api/v1/healthMinimal process health check without internal details.
    Purpose
    Minimal process health check without internal details.
    Access and scope
    Public operation: no API key or scope is required.
    Parameters and body
    • No parameters or request body are declared.
    Success response
    200 · Minimal process health check without internal details.
    Errors
    OpenAPI declares no operation-specific error responses for this operation.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
  • GET/api/v1/openapi.jsonMachine-readable OpenAPI 3.1 document.
    Purpose
    Machine-readable OpenAPI 3.1 document.
    Access and scope
    Public operation: no API key or scope is required.
    Parameters and body
    • No parameters or request body are declared.
    Success response
    200 · Machine-readable OpenAPI 3.1 document.
    Errors
    OpenAPI declares no operation-specific error responses for this operation.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
  • GET/api/v1/catalogPublic catalog with filtering, sorting, and pagination.
    Purpose
    Public catalog with filtering, sorting, and pagination.
    Access and scope
    A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest catalog:read scope.
    Parameters and body
    • category · query · string · optional
    • brand · query · string[] · optional
    • search · query · string · maxLength 120 · optional
    • priceMin · query · number · min 0 · optional
    • priceMax · query · number · min 0 · optional
    • available · query · "0" | "1" · optional
    • sort · query · "featured" | "price-asc" | "price-desc" | "name" · optional
    • page · query · integer · min 1 · max 1000 · optional
    Success response
    200 · Public catalog with filtering, sorting, and pagination.
    Errors
    400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
  • GET/api/v1/contentPublished content entries, optionally filtered by scope.
    Purpose
    Published content entries, optionally filtered by scope.
    Access and scope
    A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest content:read scope.
    Parameters and body
    • scope · query · string · minLength 1 · maxLength 80 · optional
    Success response
    200 · Published content entries, optionally filtered by scope.
    Errors
    400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
  • POST/api/v1/ordersIdempotent order creation with reservation.
    Purpose
    Idempotent order creation with reservation.
    Access and scope
    A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest orders:write scope.
    Parameters and body
    • Idempotency-Key · header · string · minLength 32 · maxLength 128 · required
    • JSON body · OrderInput · required
    Success response
    200 / 201 · Idempotent order creation with reservation.
    Errors
    400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
    Important boundary
    Stable external contract. OpenAPI 3.1 fixes the exact parameters, responses, and errors exposed in the API section below.
    Open the detailed handbook walkthrough
02Storefront and customer flowsServer surface for the optional storefront; enabled and adapted per project.14 routes
  • GET/api/catalogPublic catalog projection.
    Purpose
    Public catalog projection.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Public catalog projection. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/catalog/productsBatch product lookup.
    Purpose
    Batch product lookup.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Batch product lookup. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/analytics/eventsIngest allow-listed first-party events after explicit consent without IP, User-Agent, or a full referrer.
    Purpose
    Ingest allow-listed first-party events after explicit consent without IP, User-Agent, or a full referrer.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Ingest allow-listed first-party events after explicit consent without IP, User-Agent, or a full referrer. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/contactCreate a customer request.
    Purpose
    Create a customer request.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Create a customer request. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/contentPublic content delivery.
    Purpose
    Public content delivery.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Public content delivery. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/localeCurrent interface locale.
    Purpose
    Current interface locale.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Current interface locale. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/newsletterDouble opt-in subscription.
    Purpose
    Double opt-in subscription.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Double opt-in subscription. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/newsletter/one-clickOne-click unsubscribe.
    Purpose
    One-click unsubscribe.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    One-click unsubscribe. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/order-accessIssue bounded order access.
    Purpose
    Issue bounded order access.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Issue bounded order access. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOST/api/ordersRead and create an order.
    Purpose
    Read and create an order.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Read and create an order. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOST/api/orders/:orderId/paymentPayment status and hosted payment start.
    Purpose
    Payment status and hosted payment start.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • Path parameters from the route inventory: orderId. The remaining schema stays inside the route handler contract.
    Success response
    Payment status and hosted payment start. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/orders/:orderId/payment/syncReconcile a payment with the provider.
    Purpose
    Reconcile a payment with the provider.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • Path parameters from the route inventory: orderId. The remaining schema stays inside the route handler contract.
    Success response
    Reconcile a payment with the provider. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/uploads/products/:fileServe authorized product media.
    Purpose
    Serve authorized product media.
    Access and scope
    Server surface for the optional storefront; enabled and adapted per project.
    Parameters and body
    • Path parameters from the route inventory: file. The remaining schema stays inside the route handler contract.
    Success response
    Serve authorized product media. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
03Customer accountCustomer cookie session, CSRF/origin protection, and project-specific OAuth integration.7 routes
  • POST/api/account/feedbackAuthenticated customer request.
    Purpose
    Authenticated customer request.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Authenticated customer request. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • PATCH/api/account/profileUpdate the customer profile.
    Purpose
    Update the customer profile.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Update the customer profile. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/account/reviewsSubmit an account review.
    Purpose
    Submit an account review.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Submit an account review. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOSTDELETE/api/account/sessionInspect, create, and end a session.
    Purpose
    Inspect, create, and end a session.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Inspect, create, and end a session. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/account/sessionsManage other sessions.
    Purpose
    Manage other sessions.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Manage other sessions. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POSTDELETE/api/account/yandexConnect and disconnect Yandex ID.
    Purpose
    Connect and disconnect Yandex ID.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Connect and disconnect Yandex ID. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/account/yandex/callbackYandex ID OAuth callback.
    Purpose
    Yandex ID OAuth callback.
    Access and scope
    Customer cookie session, CSRF/origin protection, and project-specific OAuth integration.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Yandex ID OAuth callback. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
04Internal Studio surfaceNot an external API: requires an admin session and may evolve with the release UI.22 routes
  • GET/api/admin/analytics/trafficPrivacy-first traffic aggregates for 7, 30, or 90 days and the matching previous period.
    Purpose
    Privacy-first traffic aggregates for 7, 30, or 90 days and the matching previous period.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Privacy-first traffic aggregates for 7, 30, or 90 days and the matching previous period. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOSTPATCHDELETE/api/admin/catalogCatalog snapshot and mutations.
    Purpose
    Catalog snapshot and mutations.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Catalog snapshot and mutations. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/catalog/exportCatalog and stock exports.
    Purpose
    Catalog and stock exports.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Catalog and stock exports. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/catalog/metadataCategory and filter metadata.
    Purpose
    Category and filter metadata.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Category and filter metadata. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/catalog/productsFilterable product list.
    Purpose
    Filterable product list.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Filterable product list. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/catalog/products/:productIdComplete product record.
    Purpose
    Complete product record.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: productId. The remaining schema stays inside the route handler contract.
    Success response
    Complete product record. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/catalog/sku-registryRow-level SKU registry with filters, sorting, and cursor pagination.
    Purpose
    Row-level SKU registry with filters, sorting, and cursor pagination.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Row-level SKU registry with filters, sorting, and cursor pagination. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOSTPATCHDELETE/api/admin/contentContent and marketing placements.
    Purpose
    Content and marketing placements.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Content and marketing placements. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOST/api/admin/email-campaignsCampaign audiences, previews, enqueue, and monitoring.
    Purpose
    Campaign audiences, previews, enqueue, and monitoring.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Campaign audiences, previews, enqueue, and monitoring. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/email-diagnosticsSafe email transport diagnostics.
    Purpose
    Safe email transport diagnostics.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Safe email transport diagnostics. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOSTPATCHDELETE/api/admin/operationsOrders, contacts, reviews, and audit operations.
    Purpose
    Orders, contacts, reviews, and audit operations.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Orders, contacts, reviews, and audit operations. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/operations/exportServer-side operations CSV exports.
    Purpose
    Server-side operations CSV exports.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Server-side operations CSV exports. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/operations/historyCursor-based operations history.
    Purpose
    Cursor-based operations history.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Cursor-based operations history. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOST/api/admin/paymentsPayment list and compatibility action endpoint.
    Purpose
    Payment list and compatibility action endpoint.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Payment list and compatibility action endpoint. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/api/admin/payments/:paymentIdPayment details.
    Purpose
    Payment details.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: paymentId. The remaining schema stays inside the route handler contract.
    Success response
    Payment details. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/payments/:paymentId/cancelIdempotent payment cancellation.
    Purpose
    Idempotent payment cancellation.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: paymentId. The remaining schema stays inside the route handler contract.
    Success response
    Idempotent payment cancellation. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/payments/:paymentId/captureCapture a two-stage payment.
    Purpose
    Capture a two-stage payment.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: paymentId. The remaining schema stays inside the route handler contract.
    Success response
    Capture a two-stage payment. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/payments/:paymentId/refundsFull or partial refund.
    Purpose
    Full or partial refund.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: paymentId. The remaining schema stays inside the route handler contract.
    Success response
    Full or partial refund. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POST/api/admin/payments/:paymentId/syncReconcile status with YooKassa.
    Purpose
    Reconcile status with YooKassa.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • Path parameters from the route inventory: paymentId. The remaining schema stays inside the route handler contract.
    Success response
    Reconcile status with YooKassa. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • POSTDELETE/api/admin/sessionToken/TOTP sign-in and sign-out.
    Purpose
    Token/TOTP sign-in and sign-out.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Token/TOTP sign-in and sign-out. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPATCH/api/admin/sessionsList and revoke administrative sessions.
    Purpose
    List and revoke administrative sessions.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    List and revoke administrative sessions. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GETPOSTDELETE/api/admin/uploadsUpload, list, and delete media.
    Purpose
    Upload, list, and delete media.
    Access and scope
    Not an external API: requires an admin session and may evolve with the release UI.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Upload, list, and delete media. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
05Integrations and operationsWebhook and probes for the provider, load balancer, orchestrator, and monitoring.4 routes
  • POST/api/webhooks/payments/yookassaYooKassa signal followed by mandatory provider API verification.
    Purpose
    YooKassa signal followed by mandatory provider API verification.
    Access and scope
    Webhook and probes for the provider, load balancer, orchestrator, and monitoring.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    YooKassa signal followed by mandatory provider API verification. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/healthProcess liveness.
    Purpose
    Process liveness.
    Access and scope
    Webhook and probes for the provider, load balancer, orchestrator, and monitoring.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Process liveness. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/health/readyApplication and dependency readiness.
    Purpose
    Application and dependency readiness.
    Access and scope
    Webhook and probes for the provider, load balancer, orchestrator, and monitoring.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Application and dependency readiness. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
  • GET/humans.txtPublic delivery information.
    Purpose
    Public delivery information.
    Access and scope
    Webhook and probes for the provider, load balancer, orchestrator, and monitoring.
    Parameters and body
    • There are no path parameters. Query/body fields remain an internal handler contract and are not part of stable OpenAPI v1.
    Success response
    Public delivery information. The exact status/body is defined by the current release handler.
    Errors
    Failure statuses and error bodies may evolve with this internal surface; external clients should use /api/v1 or a dedicated adapter.
    Important boundary
    The inventory proves the path and methods exist without turning an internal endpoint into an external compatibility promise.
    Open the detailed handbook walkthrough
03 / PUBLIC API V1

A stable surface
for integrations.

The public API is separated from internal Studio routes. It is versioned, exposed as OpenAPI 3.1, and accompanied by a dependency-free TypeScript client.

GET/api/v1publicDiscover the API version, authentication, and resources./api/demo/v1
Purpose
Discover the API version, authentication, and resources.
Access and scope
Public operation: no API key or scope is required.
Parameters and body
  • No parameters or request body are declared.
Success response
200 · Discover the API version, authentication, and resources.
Errors
OpenAPI declares no operation-specific error responses for this operation.
Important boundary
This public operation needs no key. Use the response for capability discovery, never for storing secrets.
Production
/api/v1
Demo
/api/demo/v1
Rate limit
Request example
curl --fail-with-body https://api.example.com/api/v1
Response shape
{
  "name": "foundry-public-api",
  "version": "v1",
  "openapi": "/api/v1/openapi.json",
  "authentication": { "headers": ["Authorization", "X-API-Key"] },
  "resources": { "catalog": { "method": "GET", "path": "/api/v1/catalog" } }
}
Open the detailed handbook walkthrough
GET/api/v1/healthpublicMinimal process health check without internal details./api/demo/v1/health
Purpose
Minimal process health check without internal details.
Access and scope
Public operation: no API key or scope is required.
Parameters and body
  • No parameters or request body are declared.
Success response
200 · Minimal process health check without internal details.
Errors
OpenAPI declares no operation-specific error responses for this operation.
Important boundary
This confirms that the process is alive but does not verify the database or configuration. Use a separate readiness check for the live load balancer.
Production
/api/v1/health
Demo
/api/demo/v1/health
Rate limit
Request example
curl --fail-with-body https://api.example.com/api/v1/health
Response shape
{
  "status": "ok",
  "service": "foundry-public-api",
  "version": "v1",
  "timestamp": "2026-08-09T12:00:00.000Z"
}
Open the detailed handbook walkthrough
GET/api/v1/openapi.jsonpublicMachine-readable OpenAPI 3.1 document./api/demo/v1/openapi.json
Purpose
Machine-readable OpenAPI 3.1 document.
Access and scope
Public operation: no API key or scope is required.
Parameters and body
  • No parameters or request body are declared.
Success response
200 · Machine-readable OpenAPI 3.1 document.
Errors
OpenAPI declares no operation-specific error responses for this operation.
Important boundary
The schema is the machine-readable API v1 contract. Pin generated clients to the delivered release.
Production
/api/v1/openapi.json
Demo
/api/demo/v1/openapi.json
Rate limit
Request example
curl --fail-with-body https://api.example.com/api/v1/openapi.json > furazhir.openapi.json
Response shape
{
  "openapi": "3.1.0",
  "info": { "title": "Фуражир Public API", "version": "v1" },
  "paths": { "/api/v1/catalog": {}, "/api/v1/orders": {} }
}
Open the detailed handbook walkthrough
GET/api/v1/catalogcatalog:read600 / minPublic catalog with filtering, sorting, and pagination./api/demo/v1/catalog
Purpose
Public catalog with filtering, sorting, and pagination.
Access and scope
A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest catalog:read scope.
Parameters and body
  • category · query · string · optional
  • brand · query · string[] · optional
  • search · query · string · maxLength 120 · optional
  • priceMin · query · number · min 0 · optional
  • priceMax · query · number · min 0 · optional
  • available · query · "0" | "1" · optional
  • sort · query · "featured" | "price-asc" | "price-desc" | "name" · optional
  • page · query · integer · min 1 · max 1000 · optional
Success response
200 · Public catalog with filtering, sorting, and pagination.
Errors
400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
Important boundary
Repeat brand and attr.<code> query parameters for facets; available accepts 0 or 1.
Production
/api/v1/catalog
Demo
/api/demo/v1/catalog
Rate limit
600 / min
Request example
curl --fail-with-body \
  -H "Authorization: Bearer $FOUNDRY_API_KEY" \
  "https://api.example.com/api/v1/catalog?available=1&sort=featured&page=1"
Response shape
{
  "catalog": {
    "sections": [],
    "brands": [],
    "attributeFacets": [],
    "matchedProducts": 0,
    "totalProducts": 0
  }
}
Open the detailed handbook walkthrough
GET/api/v1/contentcontent:read600 / minPublished content entries, optionally filtered by scope./api/demo/v1/content
Purpose
Published content entries, optionally filtered by scope.
Access and scope
A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest content:read scope.
Parameters and body
  • scope · query · string · minLength 1 · maxLength 80 · optional
Success response
200 · Published content entries, optionally filtered by scope.
Errors
400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
Important boundary
The response contains the published projection only. Draft records must remain absent even when scope is requested directly.
Production
/api/v1/content
Demo
/api/demo/v1/content
Rate limit
600 / min
Request example
curl --fail-with-body \
  -H "Authorization: Bearer $FOUNDRY_API_KEY" \
  "https://api.example.com/api/v1/content?scope=storefront"
Response shape
{
  "entries": [
    { "id": "hero", "scope": "storefront", "title": "…", "body": "…", "position": 1 }
  ]
}
Open the detailed handbook walkthrough
POST/api/v1/ordersorders:write60 / 15 minIdempotent order creation with reservation./api/demo/v1/orders
Purpose
Idempotent order creation with reservation.
Access and scope
A server-side integration sends Authorization: Bearer <key> or X-API-Key with the smallest orders:write scope.
Parameters and body
  • Idempotency-Key · header · string · minLength 32 · maxLength 128 · required
  • JSON body · OrderInput · required
Success response
200 / 201 · Idempotent order creation with reservation.
Errors
400 · 401 · 403 · 405 · 413 · 415 · 429 · 500 · 503. Errors use one envelope with code, message, and requestId; rate-limit responses include X-RateLimit-* headers.
Important boundary
A new order returns 201; replaying the same operation with the same key returns 200. Every new logical order needs a new key.
Production
/api/v1/orders
Demo
/api/demo/v1/orders
Rate limit
60 / 15 min
Request example
curl --fail-with-body -X POST \
  -H "Authorization: Bearer $FOUNDRY_API_KEY" \
  -H "Idempotency-Key: 01JEXAMPLEORDER000000000000000001" \
  -H "Content-Type: application/json" \
  --data '{"customerName":"Ada Lovelace","customerEmail":"ada@example.com","customerContact":"+10000000000","deliveryId":"pickup","pickupLocationId":"pickup-main","paymentId":"card","termsAccepted":true,"itemCount":1,"totalValue":12000,"items":[{"productId":"boots-1","productName":"Winter boots","quantity":1,"priceValue":12000}]}' \
  https://api.example.com/api/v1/orders
Response shape
{
  "order": {
    "id": "order-…",
    "status": "new",
    "itemCount": 1,
    "totalValue": 12000
  }
}
Open the detailed handbook walkthrough

Authentication and responses

  • Authorization: Bearer <key> or X-API-Key; never embed a privileged key in a browser bundle.
  • Scopes: catalog:read, content:read, search:read, and orders:write.
  • Errors use one envelope, X-Request-Id, and rate-limit headers; redirects are rejected for credential-bearing SDK calls.
  • POST /api/v1/orders requires a 32–128 character Idempotency-Key.

Practical request

Production uses /api/v1. The public sandbox mirrors the contract under /api/demo/v1 and isolates state with X-Demo-Workspace.

OpenAPI 3.1
curl · catalog
curl --fail-with-body \
  -H "Authorization: Bearer $FOUNDRY_API_KEY" \
  "https://api.example.com/api/v1/catalog?available=1&sort=featured&page=1"
TypeScript SDK · order
import { FoundryClient } from "@foundry/sdk";

const foundry = new FoundryClient({
  baseUrl: "https://api.example.com",
  apiKey: process.env.FOUNDRY_API_KEY,
  timeoutMs: 10_000,
});

const result = await foundry.createOrder(order, {
  idempotencyKey: crypto.randomUUID(),
});

The SDK ships in the package and installs from a local directory or release tarball; a public npm publication is not currently claimed.

04 / INTEGRATIONS & STATUS

Shipped, configurable,
and not misrepresented.

Production features, safe sandbox workflows, and roadmap items are deliberately separated. Provider or infrastructure configuration is not hidden behind the word supported.

Production

TypeScript SDK

Fetch/URL/Headers/AbortController, typed errors, timeout/cancel, catalog, content, search, and orders.

Production

YooKassa

Hosted checkout, capture/cancel/refund, inbound webhook with provider re-fetch, and receipt fields. SBP/card/pay methods depend on the connected merchant account.

Production

SMTP + S3

Transport diagnostics, outbox/worker/retries, and S3-compatible media lifecycle; the installation owner supplies credentials.

Sandbox

Webhook center + automations

CRUD, pause/resume, test delivery, and manual runs persist in the demo, while external URLs are intentionally never called.

Roadmap

Shared SaaS / RBAC / SSO

Not included in the current single-tenant package; these require a separate tenant-aware baseline and hardening.

STATUS MATRIX

Commercial extensions

Sandbox means testable in Developer Hub without external delivery. Planned is a direction, not a current-version promise.

  • EXT-CRM-001roadmap

    Customer 360 and mini-CRM

    customers · segments · owner · LTV/MRR · timeline · notes · tags

  • EXT-RBAC-001roadmap

    Team, roles and permissions

    users · roles · permissions · invites

  • EXT-APIKEY-001sandbox shipped

    Scoped API keys

    one-time secret · token hint · scopes · environment · last used · revocation

  • EXT-WEBHOOK-001sandbox shipped

    Webhook and integration center

    subscriptions · signing hint · status · sandbox delivery attempts

  • EXT-AUTOMATION-001sandbox shipped

    Automation rules

    triggers · actions · status · bounded run log

  • EXT-ENVHEALTH-001sandbox shipped

    Environment and service health overview

    environments · regions · versions · service status · latency

  • EXT-PAYMENTS-001sandbox shipped

    YooKassa payment operations sandbox

    payment transaction · capture mode · refunds · configurable estimated commission · audit lifecycle

  • EXT-WHITELABEL-001roadmap

    White-label configurator

    logo · palette · typography · domain · email theme

  • EXT-SLA-001roadmap

    SLA and task inbox

    assignee · priority · due date · breach · comments

  • EXT-IMPORT-001roadmap

    CSV import jobs

    mapping · validation · preview · job history · rollback

  • EXT-VIEWS-001roadmap

    Saved views and custom fields

    view filters · columns · custom field definitions/values

  • EXT-PROCUREMENT-001roadmap

    Procurement and inventory planning

    suppliers · purchase orders · reorder points · forecast

05 / DEPLOYMENT

Runs inside
your environment.

The baseline is one isolated installation per customer. Web, migrations, and worker roles are separated; PostgreSQL remains the source of truth.

  1. 01

    Bootstrap

    Generates local secrets, admin token, TOTP, and API key; existing configuration is never silently overwritten.

  2. 02

    Migrate

    A separate one-shot role applies immutable PostgreSQL migrations before the application starts.

  3. 03

    Run

    Web serves Studio/API while a dedicated worker processes outbox, retries, and retention.

  4. 04

    Verify

    Liveness, readiness, worker heartbeat, PostgreSQL/TLS, SMTP, and S3 probes are part of acceptance.

Compatibility matrix

Runtime
Node.js 22–24
Containers
Docker + Compose plugin
Data
PostgreSQL; separate database per deployment
Media
S3-compatible storage, optional
Email
SMTP with TLS verification
Cloud
Timeweb Cloud or another Docker/private-network IaaS
06 / SECURITY BOUNDARY

Controls are built in.
Certificates are not simulated.

FURAZHIR ships technical controls, but it cannot certify a specific law or standard on its own: compliance depends on the buyer’s data, region, contracts, and operations.

BASELINE

Baseline controls

  • token + TOTP, server-side sessions, and active-session revocation
  • CSRF/origin checks, an exact CORS allow-list, and bounded payloads
  • rate limits, idempotency, and optimistic concurrency
  • typed audit without secrets or raw binary data
  • verified provider webhook followed by an authenticated API re-fetch
  • PostgreSQL TLS, private S3, backup/restore, and rollback as required production-launch checks
BOUNDARY

Honest v1 boundary

  • single-tenant by deployment, not a shared multi-tenant SaaS
  • resource RBAC, memberships, SSO/SCIM, HA, and certified compliance are separate work
  • the public demo uses synthetic data and isolated storage only
  • a live installation uses the project brand, verified seller details, and reviewed security settings
07 / LICENSE & DELIVERY

Core model.
One production installation.

The intended model is perpetual use of the delivered version in one isolated production installation, with 30 days of launch support and updates. Exact contents, rights, and terms are fixed in the license, order, and agreement before payment.

What a buyer receives

  • versioned source archive or signed OCI images, as agreed
  • Compose configuration, migrations, and a secret-free .env.example
  • bootstrap, health, backup/restore, and rollback runbooks
  • OpenAPI, TypeScript SDK, and integration examples
  • license certificate, release notes, SBOM, NOTICE, and checksums
  • 30 days of launch support and core updates

Rights arise from the license and agreed order. This page helps evaluate the package, but does not itself grant a right to receive or copy source code and is not an offer.

VERIFY BEFORE APPLYING

The complete surface is open
for an honest evaluation.

Start with the full panel, then verify the operations you need against this page and OpenAPI. Request a technical consultation so delivery, terms, and the agreement are clear before work begins.

Open the demo panelDiscuss a project