Reference /docs
The exact inventory: what ships, status, surfaces, APIs, and delivery boundaries.
FURAZHIR FIELD MANUAL / EN
More than a feature list.
A handbook for the whole system.
A step-by-step path from the first Docker start to API integration, safe operations, and customer handoff. Learn not only what FURAZHIR contains, but why it exists and how the pieces connect.
Built from the verified capability catalog · 2026-08-09
FFIELD MANUAL · 01
OPERATING SYSTEMS
FURAZHIRv2026-08-09FIELD MANUAL
Panel · API · Runtime · Delivery
- 10
- learning chapters
- 94
- panel capabilities
- 39
- command contracts
- 54
- server routes
Two documentation modes
↗
Handbook /learn
The sequence: what to do, why it works this way, where to verify it, and what result is correct.
CHOOSE A TRACK
One handbook, three useful paths
Your selection updates the contents and curriculum below. The URL keeps the track, and you can restore every chapter at any time.CURRICULUM
From zero to an accepted delivery
The chapters follow the actual working order. Read them in sequence or choose a track above; links lead to the live demo and exact reference.0112 min
Build the right product model
Chapter outcome
Understand the admin panel, stable API, background processes, and separate customer installation before configuring anything.
Key concepts
- admin panel
- API v1
- background jobs and queue
- separate installation
- A list of people and systems that read or change data.
- The data the business treats Фуражир as the source of truth for.
- An owner for every external effect: email, webhook, payment, or export.
From people and clients to one domain core
01OperatorPanel and server session
02IntegrationAPI v1, key, minimal permissions
03DomainValidation, version, command
04PostgreSQLSource of truth and queue
05Background jobsRetryable external work
01The panel is a workplace; the API is the contract
The panel can evolve with staff workflows. Integrations depend only on versioned /api/v1 and its OpenAPI description, so a panel redesign does not break customer connections.
02The transaction ends in the database
An HTTP command validates input, checks the record version, and atomically saves the change with a delivery job. Email and provider availability do not decide whether the primary operation commits.
03A read model is not the source of truth
Search, analytics, and public projections can be rebuilt from canonical tables. They accelerate reads but do not independently decide reservations, state transitions, or publication rights.
04Each customer has a separate installation
One installation belongs to one customer, with separate secrets, database, domain, and backups. That reduces the impact of an incident and keeps data ownership clear.
Work through the steps
01Separate the interfaces
The admin panel serves operators, /api/v1 serves external integrations, and a separate process owns background actions. Service /api/admin routes are not a stable customer API.
02Choose the source of truth
Live data uses one PostgreSQL database per customer installation. The panel, API, and background jobs share the same domain rules.
03Write down the boundary
Every customer receives a separate installation. Advanced roles, corporate sign-in, and high availability are agreed for the project.
- Connecting a storefront to internal /api/admin routes.
- Calling email or webhooks inside the transactional HTTP request.
- Promising RBAC, SSO, HA, or multi-tenancy without separate design and acceptance.
- Consumer → interface → permission → owner matrix.
- Source-of-truth and rebuildable-view diagram.
- Provider-failure test with a retryable delivery job.
- Architecture note recording the separate-installation boundary.
Draw the three consumers in your project and map each one to the admin panel, API v1, or a system integration.
No browser client depends on /api/admin, and deferred effects do not run inside a user HTTP request.
0220 min
Run the complete local environment
Chapter outcome
Start the site, admin panel, PostgreSQL, background jobs, and test mail as one verifiable environment.
Key concepts
- Docker Compose
- test-only keys
- service checks
- sample data
- Docker Engine with Compose v2 and enough memory for the full stack.
- The local ports listed in the start guide are available.
- Agreement that the local stack uses sample data and test-only credentials.
One smoke crosses the complete product
01SiteLocal address
02Panel and APILocal address
03Background jobsQueue processing
04PostgreSQLSample state
05MailpitTest messages
01Compose is the executable system map
Services do more than start together: healthchecks and dependencies encode order, while the private network separates internal dependencies from published loopback ports.
02Local secrets are disposable
The environment generator writes an ignored file with test values. It makes the stack reproducible but is never a transport for live payment credentials, second-factor data, or provider keys.
03Smoke verifies a path, not a port
The full check crosses the site, panel, API, background jobs, and test mailbox. A successful TCP connection is insufficient; useful responses and sample state changes are asserted.
04Reset is part of the test contract
The demo returns to a known state without hand-editing tables. Repeated runs stay comparable and cannot silently depend on stale data.
Work through the steps
01Create local secrets
This creates ignored test-only files. Never put live payment credentials or real personal data into the local stack.
cd services/regional-checkout npm run local:env02Start the containers
Docker Compose waits for the site, panel, background jobs, database, and test mail to become ready.
npm run local:up03Prove connectivity
The full check covers the main user flows, service-to-service data exchange, and sample-state reset.
npm run local:smoke:full
- Publishing local ports on 0.0.0.0 on a shared network.
- Using live YooKassa keys or real personal data.
- Treating process start as readiness before dependencies respond.
- docker compose ps with healthy states.
- Complete local:smoke:full log covering every role.
- A sample message in Mailpit correlated to the operation.
- A second successful check after reset.
Open the local site, admin panel, and test mailbox using the addresses in the setup guide.
The full check passes and every published port is bound to 127.0.0.1 only.
0315 min
Sign in and verify edit safety
Chapter outcome
Learn token + TOTP, server sessions, themes, locales, and unsaved-change protection.
Key concepts
- TOTP
- server session
- optimistic concurrency
- unsaved guard
- Separate test-only admin token and TOTP seed.
- Two independent browser sessions for conflict and revoke tests.
- HTTPS and secure cookie settings outside localhost.
From strong sign-in to a verifiable mutation
01Token + TOTPOne-time sign-in proof
02Server sessionTTL, HttpOnly, revoke
03Entity versionOptimistic concurrency
04MutationAtomic state change
05AuditWho changed what and when
01The sign-in secret does not become the session
Token and TOTP prove sign-in, then the server issues a bounded, revocable session. Routine requests do not keep replaying the original secret.
02Sessions belong to the server
Active-device listing and revocation are checked against server state. Deleting one browser cookie is not a revocation mechanism for other sessions.
03Entity versions stop silent overwrite
The editor sends the expected version. If another session already saved, the server rejects stale input and returns enough context for an intentional comparison.
04The unsaved guard closes the client-side gap
Navigation, section changes, and page close warn about a dirty form. This complements server concurrency; it never replaces it.
Work through the steps
01Sign in without sharing a secret
Read FOUNDRY_ADMIN_TOKEN and the TOTP seed from the ignored local env. Never paste either value into issues, logs, or chat.
02Create a conflict
Open one entity in two tabs, save a change in the first tab, and try to save the stale version in the second.
03Verify sign-out
Revoke another session and confirm the server rejects its next request.
- Keeping a bootstrap token in localStorage or publishing a TOTP seed.
- Implementing sign-out only by deleting the local cookie.
- Using last-write-wins for large forms and relying only on browser warnings.
- Headers/HAR without primary secrets after login.
- Reproducible stale conflict from two sessions.
- Unsaved-guard checks for navigation, refresh, and close.
- 401 after revoke plus the matching audit event.
Change theme and locale, start editing, then try to navigate away and refresh.
Edits are not silently lost, conflicts offer recovery, and a revoked session actually stops working.
0435 min
Build a catalog from category to SKU
Chapter outcome
Use all six catalog modes, attribute schemas, variants, stock, media, filters, and atomic saves.
Key concepts
- category schema
- SKU matrix
- stock
- atomic batch
- An agreed category taxonomy and required attributes.
- SKU, stock-unit, price, and storefront-availability rules.
- Prepared images and translations with no real data in demo.
Schema before variants, projection after atomic write
01CategorySchema and allowed attributes
02ProductContent, media, locales, labels
03SKU matrixUnique combinations
04StockAvailable, reserved, visibility
05Public catalogPublished facets and variants
01The category defines the valid shape
A category schema defines attribute type, requirement, and allowed values. Products and variants depend on it, so an incompatible schema change requires an explicit migration rather than silent deletion.
02Product and SKU have different jobs
The product owns shared content and merchandising; the SKU owns a concrete attribute combination, price, stock, and availability. Duplicate combinations are rejected by the domain contract.
03Media and translations save as a set
Gallery order, alt text, localized names, and shared labels belong to one card but keep their own rules. Upload deletion is allowed only after checking current-session ownership and references.
04The public catalog is a controlled view
The storefront receives available variants, published content, and allowed filters only. An atomic batch updates the source before the public view is read as a consistent snapshot.
Work through the steps
01Schema first
Create the category and its attributes before variants. The SKU matrix must come from a validated schema, not arbitrary fields.
02Product second
Fill merchandising, translations, gallery, and shared labels before creating variants and stock.
03Verify the projection
Configure storefront filters and confirm the public catalog returns the same available variants and facets.
- Creating arbitrary SKU fields before the category schema.
- Mixing product-level stock with variant stock.
- Saving card fragments independently without one atomic boundary.
- Category schema export and a four-SKU unique matrix.
- Negative tests for required and incompatible attributes.
- Panel snapshot compared with the public catalog.
- Batch rollback when one variant fails.
Create a synthetic product with two attributes and four SKUs, then export its stock.
A batch save commits the consistent set or leaves no partially updated product behind.
0530 min
Process an order and its communications
Chapter outcome
Connect reservations, order states, requests, subscriptions, reviews, and bulk actions in one operating flow.
Key concepts
- reservation
- idempotency
- cursor history
- moderation
- A test catalog with an available SKU and known opening stock.
- An allowed order-transition table with reservation effects.
- A sample customer, request, and subscription for the full flow.
One command connects the order, reservation, and history
01Idempotent POSTOne purchase intent
02New + reserveOrder and units in one transaction
03State machineAllowed transitions only
04Archive + historyLedger remains intact
05Reply / reviewDelivery and moderation
01Idempotency identifies the logical operation
The key belongs to one purchase intent, not one network attempt. The server binds it to normalized input and returns the prior result only for an exact replay.
02Reservation is unit accounting
Creation and state changes adjust available and reserved through formal rules. Archiving removes an item from the work queue without rewriting its movement history.
03Status is a finite-state machine
A command cannot jump to an arbitrary state or repeat an irreversible edge. It checks current version, the allowed edge, and all related domain writes.
04Communications preserve context
Requests, replies, and reviews link to the order but keep their own workflow and moderation. Replies use a reliable queue, so a delivery retry never creates a second logical message.
Work through the steps
01Create the order once
Repeat POST with the same Idempotency-Key and confirm the existing order is returned instead of creating a duplicate.
02Move through states
Verify allowed transitions, stock reservation effects, and archiving without losing history.
03Close the communication loop
Triage a request, place its reply in the durable queue, then create and moderate a review linked to the completed order.
- Generating a new Idempotency-Key for each retry.
- Changing order state and stock in separate requests.
- Deleting completed operations instead of archiving their history.
- 201/200 responses for one key and order id.
- Inventory ledger before and after every allowed transition.
- Forbidden-transition test with unchanged state.
- Journal and delivery history for a linked request reply.
Find an order with server search, change its priority, run a bulk action, and export the result.
Stock agrees with status, retries are safe, and every mutation is visible in audit.
0630 min
Publish content and run background work
Chapter outcome
Understand published-content delivery, email preview, durable retries, analytics, and audit.
Key concepts
- public projection
- preview
- durable queue
- audit
- A draft content entry and page block in a demo space.
- A sample audience with subscribed and unsubscribed addresses.
- Running background-job processing and an observable test mailbox.
Publication and delivery follow separate controlled paths
01DraftWorking content version
02Publish / previewExplicit decision and recipient set
03Public viewAllowed reads only
04Delivery queueRetry and deduplication
05Journal and analyticsFact and aggregate
01Draft and published content stay separate
Editors see the working version; the public API returns only content approved for publication. A direct lookup must not bypass that boundary.
02Preview freezes the actual audience
The server applies the same consent, unsubscribe, segment, and duplicate-address rules used for delivery. Approval applies to a concrete recipient set, not an abstract template.
03A reliable queue makes delivery retryable
The main transaction creates a job with a durable id. Background processing records each attempt and retries temporary failures while keeping provider responses linked to the original command.
04The journal answers who; analytics answers how many
The journal records the author and details of a change, while analytics builds aggregates. A metric never substitutes for evidence of a specific operation.
Work through the steps
01Separate draft from public
Create a content entry and marketing block, then inspect the public API before and after publishing.
02Preview first
Build the audience and server preview. Enqueue is allowed only after explicitly confirming the recipient set.
03Observe external actions
Inspect queue attempt history, retries, derived metrics, and the typed audit record.
- Returning draft content from a public endpoint when its id is known.
- Building preview in the browser from a stale subscriber list.
- Treating an analytics event as a security audit log.
- Public content response before and after publication.
- Preview excluding unsubscribed addresses with final recipient count.
- Failed → retry → delivered history for one message id.
- Linked journal entry and aggregate metric without drift.
Change content, run a demo campaign, and locate both operations in audit and analytics.
Draft content stays private, unsubscribed recipients are excluded, and background-job retries do not duplicate actions.
0740 min
Connect your first API v1 client
Chapter outcome
Walk through discovery, a scoped key, OpenAPI, catalog, content, search, and idempotent order creation.
Key concepts
- OpenAPI 3.1
- scopes
- rate limits
- Idempotency-Key
- A server-side environment where the key cannot enter a public bundle.
- A selected operation and its minimum scope.
- An HTTP client with timeout, backoff, and request-id logging.
Every request passes four explicit controls
01Server clientKey outside browser bundle
02Auth + scopeMinimum authority
03Limits + validationRate, schema, idempotency
04Domain commandOne transaction boundary
05ResponseStatus, request id, retry contract
01Discover before generating
The /api/v1 root reports version and resources, health checks the process, and OpenAPI 3.1 defines shapes. Generated clients are pinned to the delivered release schema.
02Key and scope form the boundary
The key stays on the integration server. Every request passes authentication and the exact scope check before any domain read or mutation.
03Rate limit and request id are protocol
The client distinguishes validation, auth, conflict, and throttling, stores X-Request-Id, and retries safe GETs with jittered backoff. Credential-bearing redirects are rejected.
04Retry an order with the original key
POST /orders needs a 32–128 character Idempotency-Key. After an uncertain network outcome, the client repeats the original body and key instead of inventing another operation.
Work through the steps
01Start with discovery
GET /api/v1 describes the version, authentication, and resources; /health checks the process, while /openapi.json defines the contract.
02Grant the smallest scope
Give an integration only catalog:read, content:read, search:read, or orders:write for its actual job.
03Treat errors as a contract
Log X-Request-Id, respect rate-limit headers, reject credential-bearing redirects, and retry an order only with its original idempotency key.
- Embedding an API key in an SPA, webview, or public example.
- Retrying every 4xx or following redirects with Authorization.
- Treating /health as proof that every database and external service is ready.
- Pinned OpenAPI and generated-client build result.
- Scope matrix with allowed and forbidden requests.
- 429/backoff test and redacted diagnostic log.
- Timeout/retry test with one created order.
Run the recipes below against /api/demo/v1, then switch the origin and key to your local Platform.
The client is cookie-free, keeps privileged keys out of browser bundles, and handles 200/201/4xx/429 correctly.
0835 min
Extend through commands and integrations
Chapter outcome
Use 39 domain commands, webhooks, and sandbox automations without bypassing business rules.
Key concepts
- command contract
- webhook verification
- automation
- provider re-fetch
- A precise business action and expected state change.
- A command with request fields and acceptance criteria.
- A test provider event or demo automation with no external delivery.
Every new entry ends at an existing command
01UI / API / webhookDifferent entry points
02Verify + normalizeSignature, replay, schema
03Domain commandFields and acceptance criteria
04State and queueAtomic write
05Journal / consumerObservable continuation
01The command is the unit of change
Its contract binds input, affected entities, UI/API entry, and acceptance criteria. A new interface reuses the command rather than cloning rules inside a controller.
02A webhook reports; it does not prove
Signature and replay checks filter invalid input, then the system re-fetches the object over an authenticated provider channel. The inbound body remains a signal, not the source of truth.
03Demo automation stays bounded
A scenario stores its trigger, conditions, and expected actions on sample data but never calls arbitrary URLs. That tests the model without unwanted external effects.
04Extensions need versioning and retry safety
A consumer pins the command/API version, stores a dedupe key, and survives replay. Input evolution stays compatible or becomes a new versioned contract.
Work through the steps
01Choose a command
A command contract names its request fields, changed entities, UI surface, API route, and acceptance IDs.
02Do not trust an inbound webhook
A provider signal triggers an authenticated API re-fetch. The incoming payload does not become the source of truth.
03Test without external delivery
Developer tools store notification and automation scenarios in the demo but never call arbitrary external URLs.
- Writing tables directly from a webhook or controller.
- Trusting amount, status, or ownership from inbound payload alone.
- Allowing demo scenarios to call arbitrary external URLs.
- Trace UI/API → command → state entities → acceptance IDs.
- Negative webhook signature, timestamp, and replay tests.
- Provider re-fetch correlated to request/event id.
- Consumer compatibility test pinned to the release.
Find the command below and trace it from the interface to changed data and the audit result.
The extension uses a domain command, idempotency, and audit instead of writing tables directly from a controller.
0945 min
Prepare a live deployment
Chapter outcome
Separate the web app, migrations, and background jobs; connect PostgreSQL, private storage, mail, backup, and monitoring.
Key concepts
- immutable migrations
- readiness check
- private network
- rollback
- Versioned images or source artifact, migrations, and a completed environment template.
- DNS, TLS certificate, private network, and separate dependency credentials.
- A release owner, change window, and written rollback trigger.
Traffic, data, and release have separate paths
01TLS edgeDNS, certificate, firewall
02Site and APILive/ready stateless traffic
03MigrationsOne run before release
04Postgres + private S3State, files, backup
05Background jobsQueue, heartbeat, alerts
01Migrations run once per release
An immutable migration artifact runs before the new site and background-job version and leaves a journal. Letting every replica alter the schema creates races and complicates rollback.
02Liveness and readiness answer different questions
/health proves the process is alive; readiness checks required bindings and migration compatibility. The load balancer sends traffic only to ready instances.
03Dependencies stay on the private network
PostgreSQL and S3 are not public, SMTP uses limited credentials, and the firewall exposes only TLS entry points. Secrets are supplied at start-up rather than stored in image layers.
04Restore matters more than backup existence
Schedule, retention, and encryption prove little without a restore drill. The restored system is checked for migrations, files, sign-in, and selected domain scenarios.
Work through the steps
01Migrations run separately
A one-shot container applies immutable migrations before the new web app and background jobs start.
02Readiness beats liveness
/health proves the process is alive; /health/ready proves required dependencies can accept traffic.
03Test restoration
A backup is ready only after a restore drill, and a release is ready only with a documented rollback.
- Running migrations concurrently from every site and background-job replica.
- Routing traffic on liveness alone.
- Storing secrets in Dockerfile, OCI layers, git, or public Compose.
- Migration log and schema version before traffic switch.
- Live/ready checks with healthy and failed dependencies.
- Firewall/port scan and built-image secret scan.
- Backup restore report with RPO/RTO, smoke, and rollback rehearsal.
Follow the Timeweb guide, complete the key-free environment template, and run the readiness checks in the target environment.
TLS, DNS, firewall, PostgreSQL, background jobs, mail, storage, backup, restoration, and rollback all have a verified result.
1025 min
Accept and deliver the product
Chapter outcome
Build a reproducible package and connect the technical delivery to clear order and license terms.
Key concepts
- delivery version
- component inventory
- checksums
- license terms
- A fixed delivery version with an immutable identifier.
- A clean host or isolated environment with no access to the developer's files.
- A customer-side engineer assigned to verify the package and installation.
The customer receives a reproducible system, not the author's folder
01Versioned artifactSource or signed OCI
02SBOM + checksumsInventory and integrity
03Runbooks + env contractInstall and operate
04AcceptanceClean install and smoke
05License + supportSeparate agreement boundary
01The artifact is reproducible and verifiable
Source archive or OCI images ship with checksums, SBOM, NOTICE, migrations, OpenAPI, and SDK. The recipient verifies integrity before deploying the fixed version.
02Installation does not depend on the author
Bootstrap, env contract, health, backup/restore, and rollback let a customer engineer finish a clean deployment without a hidden file or spoken command.
03Secrets move through a process, not the package
The delivery defines names, formats, generation, and rotation but never live values. Initial exchange uses an agreed secure channel and is followed by rotation.
04Technical readiness does not replace the agreement
The license, installation count, transfer rights, support term, seller details, and each party’s duties belong in the order or contract. Self-hosting and Russian data residency reduce some risks but are not automatic compliance.
Work through the steps
01Fix the package contents
List the version, source code or images, migrations, Docker Compose setup, SDK, OpenAPI, component inventory, and checksums.
02Transfer the instructions
Include initial setup, service checks, backup, restoration, rollback, and key-rotation steps. Never include the keys themselves.
03Record the terms
The license, installation count, transfer rights, seller details, and support belong in the order or contract. Russian data residency alone is not a compliance certificate.
- Sending an unversioned zip without checksum, SBOM, and inventory.
- Putting live secrets in the archive or sending them with the artifact.
- Presenting support months as the lifetime of the perpetual delivered-version license.
- Verified checksums, SBOM, NOTICE, and release inventory.
- Clean install and acceptance smoke performed by the recipient.
- Secret scan and a proven test rotation.
- Order or contract covering package contents, license, and support.
Perform a clean installation from the delivered package without access to the developer's working directory.
The customer can reproduce deployment and understands that the delivered version is perpetual while the 30 days cover support.
LAB / PUBLIC API V1
Build a safe client before writing more code.
This is the complete connection path for the stable public API. Service routes used by the admin panel are taught separately and are not external integration contracts.01The key stays server-side
Authorization: Bearer or X-API-Key never enters a public browser bundle.
02Scope stays minimal
Each integration gets only the catalog:read, content:read, search:read, or orders:write scope it needs.
03Retries are deliberate
GET can retry with backoff; an order retries only with the same 32–128 character Idempotency-Key.
04Errors are observable
Store X-Request-Id, handle 429, and never follow a redirect while carrying credentials.
Start without a key or cookie
The demo API mirrors every operation under /api/demo/v1. The first restricted request issues a temporary demo-space identifier. Retry the request with that header and reuse it for later calls.
X-Demo-Workspace: <opaque token>TypeScript SDK: the safe starting point
The dependency-free SDK always targets /api/v1, omits browser cookies, and rejects redirects on credential-bearing requests. Its installation method is listed in the agreed package contents.
import { FoundryClient } from "@foundry/sdk";
const foundry = new FoundryClient({
baseUrl: "https://api.example.com",
apiKey: process.env.FOUNDRY_API_KEY,
timeoutMs: 10_000,
});
const { catalog } = await foundry.getCatalog({
available: true,
sort: "featured",
});
const order = await foundry.createOrder(input, {
idempotencyKey: crypto.randomUUID(),
});GET
/api/v1Discover the API version, authentication, and resources.
Live API
/api/v1Sandbox
/api/demo/v1Scope
publicLimit
—This public operation needs no key. Use the response for capability discovery, never for storing secrets.
curl --fail-with-body https://api.example.com/api/v1{
"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" } }
}GET
/api/v1/healthMinimal process health check without internal details.
Live API
/api/v1/healthSandbox
/api/demo/v1/healthScope
publicLimit
—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.
curl --fail-with-body https://api.example.com/api/v1/health{
"status": "ok",
"service": "foundry-public-api",
"version": "v1",
"timestamp": "2026-08-09T12:00:00.000Z"
}GET
/api/v1/openapi.jsonMachine-readable OpenAPI 3.1 document.
Live API
/api/v1/openapi.jsonSandbox
/api/demo/v1/openapi.jsonScope
publicLimit
—The schema is the machine-readable API v1 contract. Pin generated clients to the delivered release.
curl --fail-with-body https://api.example.com/api/v1/openapi.json > furazhir.openapi.json{
"openapi": "3.1.0",
"info": { "title": "Фуражир Public API", "version": "v1" },
"paths": { "/api/v1/catalog": {}, "/api/v1/orders": {} }
}GET
/api/v1/catalogPublic catalog with filtering, sorting, and pagination.
Live API
/api/v1/catalogSandbox
/api/demo/v1/catalogScope
catalog:readLimit
600 / minRepeat brand and attr.<code> query parameters for facets; available accepts 0 or 1.
curl --fail-with-body \
-H "Authorization: Bearer $FOUNDRY_API_KEY" \
"https://api.example.com/api/v1/catalog?available=1&sort=featured&page=1"{
"catalog": {
"sections": [],
"brands": [],
"attributeFacets": [],
"matchedProducts": 0,
"totalProducts": 0
}
}GET
/api/v1/contentPublished content entries, optionally filtered by scope.
Live API
/api/v1/contentSandbox
/api/demo/v1/contentScope
content:readLimit
600 / minThe response contains the published projection only. Draft records must remain absent even when scope is requested directly.
curl --fail-with-body \
-H "Authorization: Bearer $FOUNDRY_API_KEY" \
"https://api.example.com/api/v1/content?scope=storefront"{
"entries": [
{ "id": "hero", "scope": "storefront", "title": "…", "body": "…", "position": 1 }
]
}GET
/api/v1/searchSearch over the public catalog projection.
Live API
/api/v1/searchSandbox
/api/demo/v1/searchScope
search:readLimit
300 / minq is bounded to 120 characters and limit to 1–20. An empty result is a successful response, not an error.
curl --fail-with-body \
-H "Authorization: Bearer $FOUNDRY_API_KEY" \
"https://api.example.com/api/v1/search?q=winter%20boots&limit=10"{
"items": [
{ "title": "Winter boots", "meta": "…", "href": "/catalog/boots", "type": "product" }
]
}POST
/api/v1/ordersIdempotent order creation with reservation.
Live API
/api/v1/ordersSandbox
/api/demo/v1/ordersScope
orders:writeLimit
60 / 15 minA new order returns 201; replaying the same operation with the same key returns 200. Every new logical order needs a new key.
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{
"order": {
"id": "order-…",
"status": "new",
"itemCount": 1,
"totalValue": 12000
}
}DEVELOPER HUB / EXTENSIONS
What works in the demo and which extensions need agreement
The demo lets you verify ready capabilities with sample data. Additional capabilities enter a delivery only when separately agreed.EXT-CRM-001separate extensionCustomer 360 and mini-CRM
- State
- customers · segments · owner · LTV/MRR · timeline · notes · tags
- API
—
EXT-RBAC-001separate extensionTeam, roles and permissions
- State
- users · roles · permissions · invites
- API
—
EXT-APIKEY-001available in demoScoped API keys
- State
- one-time secret · token hint · scopes · environment · last used · revocation
- API
GET/POST/PATCH/DELETE /api/admin/developer
EXT-WEBHOOK-001available in demoWebhook and integration center
- State
- subscriptions · signing hint · status · sandbox delivery attempts
- API
GET/POST/PATCH/DELETE /api/admin/developer
EXT-AUTOMATION-001available in demoAutomation rules
- State
- triggers · actions · status · bounded run log
- API
GET/POST/PATCH/DELETE /api/admin/developer
EXT-ENVHEALTH-001available in demoEnvironment and service health overview
- State
- environments · regions · versions · service status · latency
- API
GET /api/admin/developer
EXT-PAYMENTS-001available in demoYooKassa payment operations sandbox
- State
- payment transaction · capture mode · refunds · configurable estimated commission · audit lifecycle
- API
GET/POST /api/admin/payments
EXT-WHITELABEL-001separate extensionWhite-label configurator
- State
- logo · palette · typography · domain · email theme
- API
—
EXT-SLA-001separate extensionSLA and task inbox
- State
- assignee · priority · due date · breach · comments
- API
—
EXT-IMPORT-001separate extensionCSV import jobs
- State
- mapping · validation · preview · job history · rollback
- API
—
EXT-VIEWS-001separate extensionSaved views and custom fields
- State
- view filters · columns · custom field definitions/values
- API
—
EXT-PROCUREMENT-001separate extensionProcurement and inventory planning
- State
- suppliers · purchase orders · reorder points · forecast
- API
—
The reference section starts here: product capabilities, commands, and the server routes used to deliver them.
One search across UI, state, commands, and HTTP contracts.
LAB / 94 CAPABILITIES
A lab for every capability
Every item comes from the verified capability catalog. Open a card, run the scenario with sample data, and check the expected result.01Access, navigation and edit safetyTOTP access, localization, themes, responsive behavior, loading states, and unsaved-change protection.7 capabilities
ACC-SHL-001Studio navigation and workspace summariesdelivery + demo
“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.
Desktop navigation · Mobile drawer · Per-section counts
activeSection · sectionSummaries
GET workspace snapshot
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Studio navigation and workspace summaries” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All nine platform sections remain reachable and report counts from persisted state.
Demo safety boundary
Only synthetic workspace summaries are shown.
ACC-SHL-002Dark and light themedelivery + demo
“Dark and light theme” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
Theme toggle
browser theme preference
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Dark and light theme” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Both themes retain contrast, focus, reduced-motion and forced-colors behavior.
Demo safety boundary
Theme state remains local to the browser.
ACC-SHL-003Six-locale localizationdelivery + demo
“Six-locale localization” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
Locale switcher · Localized dates, numbers and labels
locale
Localized errors and CSV headings
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Six-locale localization” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every Studio label, error, audit value and export heading switches without reload loss.
Demo safety boundary
Locale changes never alter identity or authorization.
ACC-SHL-004Workspace load, refresh and retrydelivery + demo
“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.
Loading · Load error · Retry · Refresh
workspace load state · request id · latency
GET /api/admin/catalog, /api/admin/content and /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Workspace load, refresh and retry” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Retry and refresh recover without discarding a dirty draft silently.
Demo safety boundary
No cached cross-session snapshot is rendered.
ACC-SHL-005Dirty-state counters and discard protectiondelivery + demo
“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.
Dirty badges · Save all · Discard dialog · beforeunload guard
draft baselines · dirty record ids
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Dirty-state counters and discard protection” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Navigation, refresh and exit require confirmation whenever an unsaved draft exists.
Demo safety boundary
The guard is browser-local and reveals no persisted data.
ACC-SHL-006Token plus TOTP accessdelivery + demo
“Token plus TOTP access” completes one operation in “Access, navigation and edit safety” while keeping UI, server rules, and audit on the same contract.
Demo access screen · Token and one-time-code walkthrough
sandbox access challenge · demo operator session
POST /api/admin/session · DELETE /api/admin/session
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Token plus TOTP access” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- The walkthrough creates an isolated admin session and rate-limits failed attempts.
Demo safety 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.
ACC-SHL-007Responsive and accessible interaction systemdelivery + demo
“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.
Focus trap · Focus restore · Keyboard operation · Accessible confirmations
dialog and drawer state
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Responsive and accessible interaction system” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All dialogs and bulk confirmations work by keyboard at phone and desktop widths.
Demo safety boundary
UI state is ephemeral.
02Catalog, SKUs and fulfillmentSix work modes, product cards, variants, the SKU matrix, inventory, categories, attributes, and CSV exports.17 capabilities
ACC-CAT-001Six catalog work modesdelivery + demo
“Six catalog work modes” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
operations · simple · card · categories · pickup · filters
catalog view
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Six catalog work modes” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- The six modes share filters, selection and persisted mutations without duplicate mock state.
Demo safety boundary
All modes operate only on the current synthetic workspace.
ACC-CAT-002Server catalog filters, facets and paginationdelivery + demo
“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.
Search · Status filter · Category filter · Brand filter · Load more
catalog cursor · status/category/brand/query filters · facets
GET /api/admin/catalog/products
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Server catalog filters, facets and pagination” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Facets and totals remain correct after mutations and cursor pages contain no duplicates.
Demo safety boundary
Query length, page size and scan work are bounded.
ACC-CAT-003Product CRUD and lifecycle statusdelivery + demo
“Product CRUD and lifecycle status” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Create · Edit · Delete · Active/draft/archive
products
catalog.product.create · catalog.product.update · catalog.product.delete · POST/PATCH/DELETE /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Product CRUD and lifecycle status” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Create, edit, status and delete survive reload and emit typed audit events.
Demo safety boundary
Capacity and string limits prevent unbounded workspace growth.
ACC-CAT-004Complete product identity and merchandising fieldsdelivery + demo
“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.
Full product card
categoryId · brandId · brand · name · description · priceValue · href · status · defaultVariantId
catalog.product.create · catalog.product.update · GET /api/admin/catalog/products/:id
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Complete product identity and merchandising fields” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every platform product field round-trips and is represented in public catalog projection where appropriate.
Demo safety boundary
Links are validated as relative or allow-listed demo URLs.
ACC-CAT-005Product and catalog translationsdelivery + demo
“Product and catalog translations” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
RU/EN/FR/ZH-CN/DE/ES translation editors
product translations · category translations · attribute translations · option translations · filter translations
catalog.product.update · catalog.category.upsert · catalog.filters.batch-update · Localized catalog projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Product and catalog translations” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Locale selection changes catalog labels without mutating canonical identifiers.
Demo safety boundary
Text-only translated values are length bounded.
ACC-CAT-006Product and variant imagesdelivery + demo
“Product and variant images” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Upload controls · Preview · Alt text · Gallery editor
uploads · product image · product gallery · variant image · variant gallery
upload.create · upload.delete · catalog.product.update · catalog.variant.update · POST/GET/DELETE /api/admin/uploads
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Product and variant images” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- An uploaded image is visible only to its session, can be assigned, removed and is deleted on reset or expiry.
Demo safety boundary
Session-owned R2 objects, magic-byte validation, SVG denial, byte quotas and TTL cleanup are mandatory.
ACC-CAT-007Shared product labels and legacy swatchesdelivery + demo
“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.
Shared label picker · Create label · Swatch editor
productLabels · product label reference · swatches
catalog.label.create · catalog.product.update · POST /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Shared product labels and legacy swatches” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A shared label can be created once, reused and audited; valid swatches persist.
Demo safety boundary
Labels and colors are bounded synthetic metadata.
ACC-CAT-008Variant and SKU CRUDdelivery + demo
“Variant and SKU CRUD” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Add · Duplicate · Remove · Quick edit · Default variant
variants · SKU · price · stock · reserved · status
catalog.variant.create · catalog.variant.update · catalog.variant.delete · catalog.variant.batch-update · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Variant and SKU CRUD” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- SKU identity is case-insensitively unique and stock can never fall below reserved quantity.
Demo safety boundary
Variant count, SKU length and numeric ranges are bounded.
ACC-CAT-009Universal SKU matrixdelivery + demo
“Universal SKU matrix” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Axis selection · Matrix rebuild · Bulk price/stock/status · Matrix paging
variant axes · selected option combinations · matrix drafts
catalog.variant.batch-update · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Universal SKU matrix” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Matrix rebuild produces each selected canonical combination exactly once and preserves compatible edits.
Demo safety boundary
Combination count and variants per product are capped.
ACC-CAT-010Product-level universal attributesdelivery + demo
“Product-level universal attributes” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Typed product attribute editor
product attribute values · immutable order snapshots
catalog.product.update · Catalog and order projections
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Product-level universal attributes” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Required and typed attributes validate and category changes retain only compatible values.
Demo safety boundary
Values are validated against the current category schema.
ACC-CAT-011Catalog validation and edit readinessdelivery + demo
“Catalog validation and edit readiness” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Inline errors · Readiness summary · Guided empty state
validation issues · dirty baselines
Structured validation errors
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Catalog validation and edit readiness” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Client and server reject the same duplicate SKU, invalid schema, price, stock and reserve cases.
Demo safety boundary
Invalid records never reach persisted state.
ACC-CAT-012Category CRUD and orderingdelivery + demo
“Category CRUD and ordering” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Category manager
categories · product counts
catalog.category.upsert · catalog.category.delete · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Category CRUD and ordering” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- ID, label, title, description, status and position persist and counts remain correct.
Demo safety boundary
Deletion is blocked when referential rules would be violated.
ACC-CAT-013Category attribute schemas and option librariesdelivery + demo
“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.
Attribute and option schema editor
schema revision/status · attribute definitions · attribute options
catalog.category.upsert · Catalog metadata projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Category attribute schemas and option libraries” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All scope, type, display, unit, help, required, filterable, searchable, comparable, option and translation constraints match platform validation.
Demo safety boundary
Attribute and option counts, identifiers and color values are capped and validated.
ACC-CAT-014Storefront filter configurationdelivery + demo
“Storefront filter configuration” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Filter label/status/order/translation editor
filterSettings
catalog.filters.batch-update · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Storefront filter configuration” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Search, brand, price, availability and sort settings update atomically and affect public catalog metadata.
Demo safety boundary
Only the five supported filter identifiers are accepted.
ACC-CAT-015Pickup locations, time slots and courier deliverydelivery + demo
“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.
Pickup manager · Time-slot editor · Courier toggle
pickupLocations · timeSlots · courierDeliveryEnabled
catalog.pickup.upsert · catalog.pickup.delete · catalog.fulfillment.update · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Pickup locations, time slots and courier delivery” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Location and time-slot CRUD, status and ordering immediately affect order and storefront projections.
Demo safety boundary
Addresses are synthetic and no logistics provider is contacted.
ACC-CAT-016Atomic catalog batch savedelivery + demo
“Atomic catalog batch save” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Save all · Dirty count
product and variant draft set
catalog.product.batch-update · catalog.variant.batch-update · PATCH /api/admin/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Atomic catalog batch save” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Either all validated patches commit under the expected revision or none do.
Demo safety boundary
Batch length and serialized state size are bounded.
ACC-CAT-017Server stock exportdelivery + demo
“Server stock export” completes one operation in “Catalog, SKUs and fulfillment” while keeping UI, server rules, and audit on the same contract.
Stock CSV download
products · variants
POST /api/admin/catalog/export
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Server stock export” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- CSV includes complete SKU stock/reserve/status rows and returns count/truncation headers.
Demo safety boundary
Export is synthetic, rate-limited, size-capped and audited.
03Orders and fulfillment operationsReservation-aware statuses, search, archive, priorities, bulk actions, exports, and idempotent creation.10 capabilities
ACC-ORD-001Active and archived order flowsdelivery + demo
“Active and archived order flows” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Active flow · Archive flow · Restore
orders · archivedAt
order.archive-batch · GET/PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Active and archived order flows” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Archive and restore preserve the record and remove it from the opposite flow immediately.
Demo safety boundary
Only synthetic orders are changed.
ACC-ORD-002Server order search, filters and cursor historydelivery + demo
“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.
Query · Flow · Status · Load more
order filters · history cursor
GET /api/admin/operations/history?resource=orders
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Server order search, filters and cursor history” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Stable cursor pages honor flow, status and query without duplicates.
Demo safety boundary
Query and page sizes are bounded.
ACC-ORD-003Inventory-aware order status transitionsdelivery + demo
“Inventory-aware order status transitions” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Contextual transition actions
new · processing · completed · delivered · cancelled
order.update · order.batch-update · PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Inventory-aware order status transitions” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- 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 safety boundary
A status change is atomic and fails with a structured conflict when its stock/reserve effect would violate an inventory invariant.
ACC-ORD-004Priority, deadline and support notesdelivery + demo
“Priority, deadline and support notes” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Priority · Planned date · Internal note · Customer message · Overdue warning
priority normal/urgent/hold · fulfillmentDeadline · adminNote · customerNote
order.update · PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Priority, deadline and support notes” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All four support fields save together and overdue state derives from the deadline.
Demo safety boundary
Notes are synthetic text with strict lengths.
ACC-ORD-005Complete customer and fulfillment detailsdelivery + demo
“Complete customer and fulfillment details” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Order detail card
customer email/profile notes/contact method/messenger · delivery/pickup/address details/time slot/comment/payment
GET /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Complete customer and fulfillment details” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every optional detail renders conditionally with the same labels and fallback rules as platform.
Demo safety boundary
Seeded contacts use reserved example domains and fictitious addresses.
ACC-ORD-006Order items and immutable attribute snapshotsdelivery + demo
“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.
Line-item list
order items · variant id · quantity · price · attribute snapshots
Order response
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Order items and immutable attribute snapshots” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Changing a product schema after order creation does not change the order's displayed item attributes.
Demo safety boundary
Order snapshots contain only synthetic catalog data.
ACC-ORD-007Order summary and risk indicatorsdelivery + demo
“Order summary and risk indicators” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Command statistics · Urgent and overdue highlights
status/priority/deadline counts · visible revenue
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Order summary and risk indicators” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Counts and revenue recalculate after every visible mutation.
Demo safety boundary
Metrics are derived, not separately persisted.
ACC-ORD-008Bulk order operationsdelivery + demo
“Bulk order operations” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
Select shown · Limit 500 · Bulk status/archive/restore · Confirmation dialog
selected order ids
order.batch-update · order.archive-batch · PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Bulk order operations” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Bulk updates are atomic, affect only selected IDs and add a bounded audit payload.
Demo safety boundary
Selection and body sizes are bounded; confirmation names the impact.
ACC-ORD-009Server-filtered order exportdelivery + demo
“Server-filtered order export” completes one operation in “Orders and fulfillment operations” while keeping UI, server rules, and audit on the same contract.
CSV export
current order filters
POST /api/admin/operations/export
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Server-filtered order export” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Export applies the same flow, status and query as the visible list and records an audit event.
Demo safety boundary
Rate-limited export includes synthetic rows only.
ACC-ORD-010Idempotent API order creation and reservationdelivery + demo
“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.
API Lab order example
idempotency record · order · variant reserve
POST /api/demo/v1/orders
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Idempotent API order creation and reservation” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A repeated key and identical body replays; a conflicting body fails; successful creation updates orders, stock reserve and audit.
Demo safety boundary
Only session-owned synthetic orders are created; no payment or notification leaves the sandbox.
04Subscriptions and customer requestsDouble opt-in, unsubscribe, request triage, bulk statuses, outbox-backed replies, and exports.8 capabilities
ACC-COM-001Newsletter subscription recordsdelivery + demo
“Newsletter subscription records” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
Subscription list and detail
contact identity · source · status · consent and confirmation timestamps
contact.update · GET/PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Newsletter subscription records” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Pending, confirmed and unsubscribed states preserve consent and lifecycle metadata.
Demo safety boundary
All addresses use reserved example domains.
ACC-COM-002Feedback request recordsdelivery + demo
“Feedback request records” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
Feedback list and detail
name · email · contact · contact method · messenger · message · source · customer key
contact.update · GET/PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Feedback request records” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every platform contact field renders and can be searched without mixing newsletter rows.
Demo safety boundary
The public demo warns against real personal data and stores bounded synthetic values.
ACC-COM-003Contact search, filters and cursor historydelivery + demo
“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.
Search · Status · Load more
section/status/query filters · history cursor
GET /api/admin/operations/history?resource=contactRequests
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Contact search, filters and cursor history” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Newsletter and feedback history pages remain separate and stable under concurrent status updates.
Demo safety boundary
Query and page sizes are bounded.
ACC-COM-004Single and bulk contact status actionsdelivery + demo
“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.
Select shown · Take in work · Return to new · Archive/unsubscribe
selected contact ids · contact status
contact.update · contact.batch-update · PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Single and bulk contact status actions” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Bulk transitions are atomic and newsletter unsubscribe cannot be presented as feedback archive.
Demo safety boundary
Bulk selection is capped at 500.
ACC-COM-005Confirmed subscribers and feedback CSV exportsdelivery + demo
“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.
Export confirmed · Export feedback
current contact filters
POST /api/admin/operations/export
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Confirmed subscribers and feedback CSV exports” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Newsletter export includes confirmed recipients only; feedback export honors current filters.
Demo safety boundary
Exports are rate-limited and contain reserved-domain addresses only.
ACC-COM-006Idempotent feedback replydelivery + demo
“Idempotent feedback reply” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
Subject · Message · Queue feedback
reply subject · reply body · idempotency record · outbox item
contact.reply · POST /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Idempotent feedback reply” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A replay returns the same outbox item and does not duplicate it; successful reply marks the request processed.
Demo safety boundary
Reply is rendered and queued internally but never delivered externally.
ACC-COM-007Double opt-in and unsubscribe effectsdelivery + demo
“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.
Lifecycle metadata · Sandbox confirmation action
confirmation expiry · confirmedAt · unsubscribedAt
POST /api/demo/newsletter · POST /api/demo/newsletter/one-click
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Double opt-in and unsubscribe effects” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Confirmation is single-use and unsubscribe immediately excludes the record from future campaign snapshots.
Demo safety boundary
Signed links are session-bound and never address real recipients.
ACC-COM-008Durable reply outbox statedelivery + demo
“Durable reply outbox state” completes one operation in “Subscriptions and customer requests” while keeping UI, server rules, and audit on the same contract.
Outbox history
pending/sent/failed/skipped · attempt count · next attempt · error · sentAt
contact.reply · GET /api/admin/operations/history?resource=emailOutbox
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Durable reply outbox state” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- The reply outbox survives reload, exposes attempt metadata and is cursor-paginated.
Demo safety boundary
Terminal sandbox state is `skipped` or `sandboxed`; no SMTP connection exists.
05Reviews and moderationHome and product reviews, order linking, images, readiness checks, and bulk moderation.7 capabilities
ACC-REV-001Home and product review typesdelivery + demo
“Home and product review types” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Review type switch
reviewType home/product
review.create · review.update · GET /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Home and product review types” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Type filters and create forms preserve independent home and product workflows.
Demo safety boundary
All review authors and products are synthetic.
ACC-REV-002Review search, status filters and cursor historydelivery + demo
“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.
Search · Type · Status · Load more
type/status/query filters · history cursor
GET /api/admin/operations/history?resource=reviews
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Review search, status filters and cursor history” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- History is stable and totals reflect all matching synthetic reviews.
Demo safety boundary
Query and page sizes are bounded.
ACC-REV-003Review create, edit and deletedelivery + demo
“Review create, edit and delete” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Create mode · Moderation editor · Delete confirmation
full review record
review.create · review.update · review.delete · POST/PATCH/DELETE /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Review create, edit and delete” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- ID, author, role, rating, body, status and position round-trip and audit correctly.
Demo safety boundary
Review capacity and text length are bounded.
ACC-REV-004Delivered-order product linkingdelivery + demo
“Delivered-order product linking” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Order source and product selectors
delivered product targets · orderId · productId · productName
review.create · review.update · Operations snapshot
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Delivered-order product linking” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A product review can select a delivered item and receives its stable product identity.
Demo safety boundary
Only seeded delivered orders may be linked.
ACC-REV-005Review image and previewdelivery + demo
“Review image and preview” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Image URL · Upload · Alt text · Preview
imageSrc · imageAlt · upload ownership
upload.create · upload.delete · review.update · POST/GET/DELETE /api/admin/uploads
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Review image and preview” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A session-owned image can be previewed, saved and cleaned when no longer referenced.
Demo safety boundary
The catalog upload security policy is reused.
ACC-REV-006Review readiness and summary metricsdelivery + demo
“Review readiness and summary metrics” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Readiness pills · Character count · Summary cards
quality result · status/type/photo/rating counts
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Review readiness and summary metrics” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Readiness and all summary counts update as drafts and saved reviews change.
Demo safety boundary
Metrics are derived from current state.
ACC-REV-007Moderation and bulk review actionsdelivery + demo
“Moderation and bulk review actions” completes one operation in “Reviews and moderation” while keeping UI, server rules, and audit on the same contract.
Publish · Hide · Select shown · Save all
selected review ids · review drafts
review.update · review.batch-update · PATCH /api/admin/operations
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Moderation and bulk review actions” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Single and bulk status changes use the same exact validation and atomic persistence.
Demo safety boundary
Bulk selection and audit payload are bounded.
06Content and marketing placementsStructured text, placements, CTAs, media, batch saves, and published-only delivery.8 capabilities
ACC-CNT-001Public content groups and scopesdelivery + demo
“Public content groups and scopes” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
Content group navigation
home · marketing · catalog · product · cart · footer · legal · consent
content.entry.create · content.entry.update · GET /api/admin/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Public content groups and scopes” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Exact platform groups and scopes control filtering and public placement.
Demo safety boundary
The internal Studio scope remains hidden from public projections.
ACC-CNT-002Content search and filtersdelivery + demo
“Content search and filters” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
Search · Group/scope · Status · Reset
query · scope · status
GET /api/admin/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Content search and filters” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Counts and visible text/marketing rows honor all active filters.
Demo safety boundary
Search length is bounded.
ACC-CNT-003Text entry CRUD and positioningdelivery + demo
“Text entry CRUD and positioning” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
Composer · Inline editor · Advanced ID · Delete
id · scope · title · body · status · position
content.entry.create · content.entry.update · content.entry.delete · POST/PATCH/DELETE /api/admin/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Text entry CRUD and positioning” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All fields round-trip, order by position and publish state projects correctly.
Demo safety boundary
Text is length-bounded and always rendered as escaped plain text; operator input is never interpreted as HTML.
ACC-CNT-004Atomic text batch save and dirty overviewdelivery + demo
“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.
Dirty count · Save texts · Content quality overview
content drafts and baselines · quality overview
content.entry.batch-update · PATCH /api/admin/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Atomic text batch save and dirty overview” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Valid text patches commit atomically and dirty state clears only after server success.
Demo safety boundary
Batch size and total state bytes are bounded.
ACC-CNT-005Marketing block CRUDdelivery + demo
“Marketing block CRUD” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
Marketing editor · Delete · Placement preview
marketingBlocks
marketing.block.create · marketing.block.update · marketing.block.delete · POST/PATCH/DELETE /api/admin/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Marketing block CRUD” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Marketing blocks create, update, delete and render in their target preview.
Demo safety boundary
CTA URLs are relative or allow-listed; media obeys upload policy.
ACC-CNT-006Marketing placement, variant, layout and CTA fieldsdelivery + demo
“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.
Complete marketing editor
home-promotion/cart-advertising · text/image/mixed · fixed/content · title/text/image/alt/href/CTA/status/position
marketing.block.create · marketing.block.update · Public marketing projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Marketing placement, variant, layout and CTA fields” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All exact enums and fields validate and public projection excludes non-published blocks.
Demo safety boundary
No scriptable markup or arbitrary external asset fetch is allowed.
ACC-CNT-007Marketing batch save and media uploaddelivery + demo
“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.
Save marketing · Upload and preview
marketing drafts · upload ownership · durable orphan cleanup queue
marketing.block.batch-update · upload.create · upload.delete · PATCH /api/admin/content · POST/DELETE /api/admin/uploads
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Marketing batch save and media upload” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Batch save is atomic and replacing media schedules the previous unreferenced object for cleanup.
Demo safety boundary
R2 ownership, byte quotas and cleanup apply.
ACC-CNT-008Published-only public content projectiondelivery + demo
“Published-only public content projection” completes one operation in “Content and marketing placements” while keeping UI, server rules, and audit on the same contract.
API Lab content response
content and marketing status
GET /api/demo/v1/content
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Published-only public content projection” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Public content returns published text and marketing only and supports scope filtering.
Demo safety boundary
Draft and archived values never leave the admin projection.
07Email campaigns and outboxSMTP diagnostics, audiences, safe previews, idempotent enqueue, worker processing, and attempt history.12 capabilities
ACC-EML-001Email configuration diagnosticsdelivery + demo
“Email configuration diagnostics” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Four diagnostics cards
notifications/configuration/from/admin recipient/HELO/TLS state
GET operations snapshot
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Email configuration diagnostics” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Diagnostics explain why campaign enqueue is enabled or disabled without exposing secrets.
Demo safety boundary
Only normalized sandbox configuration is exposed; no credentials or raw transport errors.
ACC-EML-002Safe transport verificationdelivery + demo
“Safe transport verification” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Verify/check again
verification status/timestamps/failure code
email.transport.verify · POST /api/admin/email-diagnostics
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Safe transport verification” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- The rate-limited action persists a normalized result and invalidates it when sandbox configuration changes.
Demo safety boundary
Verification checks an internal deterministic sandbox transport and never opens SMTP.
ACC-EML-003Subscriber and customer audience searchdelivery + demo
“Subscriber and customer audience search” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Audience switch · Search · Pagination
audience · recipient search · recipient page
GET /api/admin/email-campaigns
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Subscriber and customer audience search” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Search totals and pages are stable for subscribers and customers separately.
Demo safety boundary
Only confirmed synthetic recipients are returned.
ACC-EML-004Selected or all-recipient campaign modedelivery + demo
“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.
Selected · All found · Select visible · 500 selection limit
selection mode · selected ids · audience snapshot
email.campaign.enqueue · POST /api/admin/email-campaigns
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Selected or all-recipient campaign mode” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Selected mode preserves exact IDs; all mode snapshots the matching audience at enqueue time.
Demo safety boundary
Recipient IDs are session-owned and addresses never leave the sandbox.
ACC-EML-005Complete campaign composerdelivery + demo
“Complete campaign composer” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Composer fields · CTA toggle · Image toggle/upload
subject · preheader · title · body · CTA · image
email.campaign.preview · email.campaign.enqueue · POST /api/admin/email-campaigns
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Complete campaign composer” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Exact platform field limits and conditional CTA/image requirements are enforced client and server-side.
Demo safety boundary
Operator HTML is rejected and every field is escaped server-side.
ACC-EML-006Server-rendered email previewdelivery + demo
“Server-rendered email preview” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Desktop/mobile preview · Placeholder and readiness state
preview html/text · sendReady · placeholder fields · draft fingerprint
email.campaign.preview · POST /api/admin/email-campaigns operation=preview
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Server-rendered email preview” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Any content edit makes the old preview stale and enqueue remains disabled until a current send-ready preview exists.
Demo safety boundary
Preview is escaped, sandboxed and has no active links or scripts.
ACC-EML-007Explicit audience confirmationdelivery + demo
“Explicit audience confirmation” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Confirmation checkbox and recipient count
confirmed draft fingerprint
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Explicit audience confirmation” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Changing content, audience or selection clears confirmation before enqueue.
Demo safety boundary
Confirmation is tied to the exact current draft and selection.
ACC-EML-008Idempotent campaign enqueuedelivery + demo
“Idempotent campaign enqueue” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Queue campaign
campaign · idempotency key and request fingerprint
email.campaign.enqueue · POST /api/admin/email-campaigns
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Idempotent campaign enqueue” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A repeated key replays one campaign; conflicting reuse fails without extra outbox rows.
Demo safety boundary
Enqueue creates sandbox records only and performs no external delivery.
ACC-EML-009Campaign preparation monitordelivery + demo
“Campaign preparation monitor” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Recent campaign cards · Refresh and auto-refresh · Run/retry sandbox queue
preparing/queued/failed/sent/partial · per-campaign recipient progress · attempt/next-at/error retry metadata
GET /api/admin/email-campaigns?mode=status · POST /api/admin/email-campaigns operation=process
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Campaign preparation monitor” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- 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 safety boundary
The first worker pass records a deterministic internal interruption; the visible retry reaches a terminal state without external delivery.
ACC-EML-010Durable outbox history and retry presentationdelivery + demo
“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.
Cursor-paginated delivery history
kind/recipient/subject/status/error/attempt/max/next/sent timestamps
GET /api/admin/operations/history?resource=emailOutbox
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Durable outbox history and retry presentation” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every field and normalized status message matches the platform presentation contract.
Demo safety boundary
Terminal delivery is sandboxed/skipped; SMTP is impossible.
ACC-EML-011Unsubscribe exclusion and worker behaviordelivery + demo
“Unsubscribe exclusion and worker behavior” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Sandbox preparation timeline
audience snapshot · unsubscribe status · per-campaign delivery counters · retry schedule
Campaign status projection · RFC one-click unsubscribe · Sandbox worker process
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Unsubscribe exclusion and worker behavior” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Recipients unsubscribed before retry become skipped, each campaign reaches an exact terminal state, and one campaign cannot consume another campaign's outbox rows.
Demo safety boundary
The deterministic worker changes only session-owned outbox records and never connects to SMTP.
ACC-EML-012Campaign image uploaddelivery + demo
“Campaign image upload” completes one operation in “Email campaigns and outbox” while keeping UI, server rules, and audit on the same contract.
Upload · URL · Alt text · Preview
campaign image upload reference
upload.create · upload.delete · POST/DELETE /api/admin/uploads
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Campaign image upload” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Preview and campaign reference the same session-owned image and reset deletes it.
Demo safety boundary
R2 ownership, quotas and TTL cleanup apply.
08Sales and inventory analyticsSales metrics and trends, inventory, commercial breakdowns, readiness indicators, and exports.7 capabilities
ACC-ANA-001Sales and stock focus switchdelivery + demo
“Sales and stock focus switch” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Sales/stock switch
analytics focus
The operation uses the section contract without a dedicated public endpoint.
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Sales and stock focus switch” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Each focus renders its complete independent metric and chart set.
Demo safety boundary
Focus is browser-local.
ACC-ANA-002Derived analytics integritydelivery + demo
“Derived analytics integrity” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Live metrics
orders/products/content/reviews/subscriptions
Workspace snapshot
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Derived analytics integrity” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every relevant mutation changes the affected selector and UI metric without manual synchronization.
Demo safety boundary
Analytics are calculated from current synthetic state and never hard-coded separately.
ACC-ANA-003Complete sales metricsdelivery + demo
“Complete sales metrics” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Nine sales metric cards
revenue/delivered/backlog/cancelled · orders/rates · unit and basket averages
Analytics projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Complete sales metrics” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All platform sales formulas have unit tests and match visible seeded totals.
Demo safety boundary
All money is synthetic RUB data.
ACC-ANA-004Sales series and commercial breakdownsdelivery + demo
“Sales series and commercial breakdowns” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Sales chart and six breakdown panels
dated sales series · order/revenue status · fulfillment/payment · category revenue · top products
Analytics projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Sales series and commercial breakdowns” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Charts preserve labels, currency/count formatting and usable empty states.
Demo safety boundary
Series are derived from seeded timestamps.
ACC-ANA-005Complete stock metricsdelivery + demo
“Complete stock metrics” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Eight stock metric cards
stock value/available/reserved/share · SKU states · risk value · low/out · publish readiness · review rating
Analytics projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Complete stock metrics” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Stock and variant mutations immediately recalculate all eight metrics.
Demo safety boundary
All values derive from the synthetic catalog.
ACC-ANA-006Stock, content, review and subscription breakdownsdelivery + demo
“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.
Eight stock and readiness panels
category stock/value · variant status · availability/risk · content/review/subscription status
Analytics projection
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Stock, content, review and subscription breakdowns” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every platform breakdown is present, labeled and has a tested empty state.
Demo safety boundary
All breakdowns derive from the same session state.
ACC-ANA-007Sales, dynamics and stock exportsdelivery + demo
“Sales, dynamics and stock exports” completes one operation in “Sales and inventory analytics” while keeping UI, server rules, and audit on the same contract.
Export orders analytics · Export dynamics · Export stock
analytics snapshot
POST catalog export for stock
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Sales, dynamics and stock exports” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every exported metric equals its visible selector value and uses localized headings.
Demo safety boundary
Exports contain synthetic values and are size-capped.
09Audit and administrative sessionsTyped mutation logs, filters, pagination, session revocation, optimistic concurrency, and limits.8 capabilities
ACC-AUD-001Typed audit event for every mutationdelivery + demo
“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.
Audit event list
action · entityType · entityId · actor · createdAt
Operations snapshot/history
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Typed audit event for every mutation” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every state-changing command emits one typed event on success and none on rejection; read-only campaign preview remains unaudited.
Demo safety boundary
No credentials, raw mail bodies or upload bytes enter audit payloads.
ACC-AUD-002Structured bounded audit payloaddelivery + demo
“Structured bounded audit payload” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
Localized payload detail
bounded before/after/domain metadata
Audit history
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Structured bounded audit payload” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Payload schemaVersion, outcome, entity IDs, changed fields and bounded before/after summaries describe each meaningful successful change; rejected mutations emit no event.
Demo safety boundary
Sensitive and long-content fields are redacted into compact metadata and the serialized demo payload is hard-capped at 8 KiB.
ACC-AUD-003Audit query and entity filterdelivery + demo
“Audit query and entity filter” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
Search · Object filter · Reset
query · entity type
GET /api/admin/operations/history?resource=auditEvents
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Audit query and entity filter” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Entity and query filters are server-compatible and totals remain accurate.
Demo safety boundary
Query length is bounded.
ACC-AUD-004Audit summary and cursor paginationdelivery + demo
“Audit summary and cursor pagination” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
Four summary cards · Entity insights · Load more
total/entity/latest summaries · history cursor
GET /api/admin/operations/history
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Audit summary and cursor pagination” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Stable pages, totals, truncation state and latest-event card agree after mutations.
Demo safety boundary
History retention and page size are bounded.
ACC-AUD-005Administrative session inventorydelivery + demo
“Administrative session inventory” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
Device labels · Current/active badges · Retry
session id/current/actor/IP/user agent/created/seen/expires
GET /api/admin/sessions
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Administrative session inventory” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- The current and seeded other sessions render with stable device and expiry metadata.
Demo safety boundary
IP values are documentation-only synthetic values; the real session token is never returned.
ACC-AUD-006Revoke other or all administrative sessionsdelivery + demo
“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.
Revoke others · Revoke all · Danger confirmation
active/revoked session state · independent HttpOnly access marker
session.revoke · PATCH /api/admin/sessions · POST/DELETE /api/admin/session
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Revoke other or all administrative sessions” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Others preserves current access; all sets the deny marker; both emit redacted audit events; only the documented demo token plus TOTP restores access.
Demo safety 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.
ACC-AUD-007Optimistic concurrency and conflict recoverydelivery + demo
“Optimistic concurrency and conflict recovery” completes one operation in “Audit and administrative sessions” while keeping UI, server rules, and audit on the same contract.
Conflict notice · Reload and retry
D1 workspace revision · domain drafts
D1 compare-and-swap revision and 409 envelope
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Optimistic concurrency and conflict recovery” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A stale write cannot silently overwrite a newer value and the UI preserves the user's draft for retry.
Demo safety boundary
Conflict errors reveal no other session data.
ACC-AUD-008Origin, payload, rate and capacity controlsdelivery + demo
“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.
Limit feedback
rate buckets · workspace mutation count · expiry
Exact-origin writes · Strict JSON · 429 and Retry-After
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Origin, payload, rate and capacity controls” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Cross-origin, oversized, malformed and over-budget requests fail before business mutation.
Demo safety boundary
Per-network and per-workspace budgets, TTL and cleanup prevent public abuse.
10Public API v1 and API LabOpenAPI 3.1, scoped API keys, a CORS allow-list, uniform errors, rate limits, and a TypeScript SDK.10 capabilities
ACC-API-001Discovery, health and OpenAPI 3.1delivery + demo
“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.
API Lab links
API version and sandbox capability summary
GET /api/demo/v1 · GET /api/demo/v1/health · GET /api/demo/v1/openapi.json
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Discovery, health and OpenAPI 3.1” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Discovery links every route and OpenAPI exactly matches implemented methods, schemas and security.
Demo safety boundary
Health exposes no internal binding identifiers or migration versions.
ACC-API-002Scoped ephemeral API keysdelivery + demo
“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.
API Lab key/scopes · Create/revoke/delete · One-time secret reveal
one-time API key secret · SHA-256 digest · id · scopes · lastUsedAt · revokedAt
Authorization Bearer · X-API-Key
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Scoped ephemeral API keys” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- A custom secret is returned once; missing, conflicting, cross-session, revoked and insufficient-scope keys fail closed without revealing key material.
Demo safety 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.
ACC-API-003Exact CORS allow-list and preflightdelivery + demo
“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.
CORS example
demo CORS allow-list
OPTIONS and protected v1 responses
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Exact CORS allow-list and preflight” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Only exact configured HTTPS demo origins receive matching CORS headers and Vary metadata.
Demo safety boundary
No wildcard or credentialed cross-origin access is allowed.
ACC-API-004Public catalog query contractdelivery + demo
“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.
Editable API Lab query
category · repeated brand · search · price min/max · availability · sort · page · attr.*
GET /api/demo/v1/catalog
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Public catalog query contract” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- All platform query parameters validate and return the same catalog semantics and pagination metadata.
Demo safety boundary
Only active synthetic products and available variants are projected.
ACC-API-005Public content contractdelivery + demo
“Public content contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
API Lab content request
published content and marketing
GET /api/demo/v1/content?scope=
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Public content contract” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Response shape and optional scope behavior match platform v1.
Demo safety boundary
Draft, archived and internal content never appears.
ACC-API-006Public search contractdelivery + demo
“Public search contract” completes one operation in “Public API v1 and API Lab” while keeping UI, server rules, and audit on the same contract.
API Lab search request
public categories and products
GET /api/demo/v1/search?q=&limit=
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Public search contract” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Response items and q/limit validation match platform v1; admin orders are not leaked.
Demo safety boundary
Search uses public projections only and bounded tokens.
ACC-API-007Public idempotent order contractdelivery + demo
“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.
Editable API Lab POST
order idempotency and reservation
POST /api/demo/v1/orders · DELETE /api/demo/v1/workspace
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Public idempotent order contract” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- 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 safety boundary
Only clearly synthetic contact data is accepted; no payment, mail, webhook or customer session is touched.
ACC-API-008Uniform errors, request and rate headersdelivery + demo
“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.
API Lab response metadata
rate bucket
error envelope · X-Request-Id · X-API-Key-Id · X-RateLimit-* · Retry-After
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Uniform errors, request and rate headers” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- Every protected success and failure response carries the documented stable envelope and headers.
Demo safety boundary
Errors expose no stack, secret, hash or cross-session data.
ACC-API-009Real-network API Labdelivery + demo
“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.
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
editable query/body/token/idempotency key · live response trace · created order handoff
GET catalog/content/search · POST orders · GET discovery/health/OpenAPI
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Real-network API Lab” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- 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 safety boundary
Endpoint selection is allow-listed; arbitrary external URLs cannot be requested.
ACC-API-010Dependency-free TypeScript SDK examplesdelivery + demo
“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.
Copyable typed examples
No domain state is mutated; verify a read model or system signal.
Kept aligned with the OpenAPI 3.1 contract and compile-tested
Mini lab
- Open the named UI surface in the complete demo panel.
- Run “Dependency-free TypeScript SDK examples” with sample data only.
- Reload the snapshot and compare state, network response, and audit record where applicable.
Exact manifest acceptance criterion
- SDK examples compile and exercise catalog, content, search and idempotent order creation.
Demo safety boundary
Examples use the ephemeral demo key and reserved data.
DOMAIN / 39 COMMANDS
Command contract atlas
A command is a safe extension point: it defines input, changed state, route, audit, and a verifiable result.catalog.product.createCreate productCatalog, SKUs and fulfillment
catalog.product.createCreate product- Command ID
CMD-CAT-PRODUCT-CREATE- Request fields
- product
- Changed entities
- products · audit
- UI surfaces
- Product card
- Routes
POST /api/admin/catalog- Covers capabilities
- ACC-CAT-003ACC-CAT-004
Exact manifest acceptance criterion
- Creates one full product and audit event atomically.
Demo safety boundary
Cap product count and validate all fields.
catalog.product.updateUpdate productCatalog, SKUs and fulfillment
catalog.product.updateUpdate product- Command ID
CMD-CAT-PRODUCT-UPDATE- Request fields
- productId · patch
- Changed entities
- products · audit
- UI surfaces
- Product card · Simple catalog
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-003ACC-CAT-004ACC-CAT-010
Exact manifest acceptance criterion
- Updates only supplied validated fields.
Demo safety boundary
Reject unknown fields and stale revisions.
catalog.product.deleteDelete productCatalog, SKUs and fulfillment
catalog.product.deleteDelete product- Command ID
CMD-CAT-PRODUCT-DELETE- Request fields
- productId
- Changed entities
- products · audit · uploads
- UI surfaces
- Delete confirmation
- Routes
DELETE /api/admin/catalog- Covers capabilities
- ACC-CAT-003
Exact manifest acceptance criterion
- Removes the product with referential checks and one audit event.
Demo safety boundary
Delete only session-owned data and schedule orphan media cleanup.
catalog.product.batch-updateBatch update productsCatalog, SKUs and fulfillment
catalog.product.batch-updateBatch update products- Command ID
CMD-CAT-PRODUCT-BATCH- Request fields
- productPatches
- Changed entities
- products · audit
- UI surfaces
- Operations save all
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-016
Exact manifest acceptance criterion
- Commits all valid patches or none.
Demo safety boundary
Cap batch at 200 and state bytes.
catalog.variant.createCreate SKU variantCatalog, SKUs and fulfillment
catalog.variant.createCreate SKU variant- Command ID
CMD-CAT-VARIANT-CREATE- Request fields
- productId · variant
- Changed entities
- variants · products · audit
- UI surfaces
- SKU editor
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-008
Exact manifest acceptance criterion
- Creates one unique SKU and optional default selection.
Demo safety boundary
Cap variants and validate canonical option signature.
catalog.variant.updateUpdate SKU variantCatalog, SKUs and fulfillment
catalog.variant.updateUpdate SKU variant- Command ID
CMD-CAT-VARIANT-UPDATE- Request fields
- productId · variantId · patch
- Changed entities
- variants · audit
- UI surfaces
- SKU editor · Operations catalog
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-008
Exact manifest acceptance criterion
- Updates SKU, media, price, stock, reserve, status or options under validation.
Demo safety boundary
Stock cannot be lower than reserve.
catalog.variant.deleteDelete SKU variantCatalog, SKUs and fulfillment
catalog.variant.deleteDelete SKU variant- Command ID
CMD-CAT-VARIANT-DELETE- Request fields
- productId · variantId
- Changed entities
- variants · products · audit · uploads
- UI surfaces
- SKU editor
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-008
Exact manifest acceptance criterion
- Deletes only the requested variant without invalidating the product.
Demo safety boundary
Preserve a valid default and clean session-owned orphans.
catalog.variant.batch-updateBatch update or rebuild SKU matrixCatalog, SKUs and fulfillment
catalog.variant.batch-updateBatch update or rebuild SKU matrix- Command ID
CMD-CAT-VARIANT-BATCH- Request fields
- productId · variantPatchesOrReplacement
- Changed entities
- variants · products · audit
- UI surfaces
- Operations save all · Universal SKU matrix
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-008ACC-CAT-009ACC-CAT-016
Exact manifest acceptance criterion
- Applies an atomic validated matrix without duplicate signatures.
Demo safety boundary
Cap combinations and serialized payload.
catalog.label.createCreate shared product labelCatalog, SKUs and fulfillment
catalog.label.createCreate shared product label- Command ID
CMD-CAT-LABEL-CREATE- Request fields
- text
- Changed entities
- productLabels · audit
- UI surfaces
- Product label field
- Routes
POST /api/admin/catalog- Covers capabilities
- ACC-CAT-007
Exact manifest acceptance criterion
- Creates or replays one normalized reusable label.
Demo safety boundary
Normalize, deduplicate and cap labels.
catalog.category.upsertCreate or update category and schemaCatalog, SKUs and fulfillment
catalog.category.upsertCreate or update category and schema- Command ID
CMD-CAT-CATEGORY-UPSERT- Request fields
- category
- Changed entities
- categories · attributeSchemas · audit
- UI surfaces
- Category manager · Attribute schema editor
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-012ACC-CAT-013
Exact manifest acceptance criterion
- Upserts full category metadata and one valid schema revision atomically.
Demo safety boundary
Cap schema and reject invalid stable identifiers.
catalog.category.deleteDelete categoryCatalog, SKUs and fulfillment
catalog.category.deleteDelete category- Command ID
CMD-CAT-CATEGORY-DELETE- Request fields
- categoryId
- Changed entities
- categories · attributeSchemas · audit
- UI surfaces
- Category delete confirmation
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-012
Exact manifest acceptance criterion
- Deletes an unreferenced category and schema only.
Demo safety boundary
Reject deletion while products reference the category.
catalog.filters.batch-updateUpdate storefront filter settingsCatalog, SKUs and fulfillment
catalog.filters.batch-updateUpdate storefront filter settings- Command ID
CMD-CAT-FILTERS-BATCH- Request fields
- filterSettings
- Changed entities
- filterSettings · audit
- UI surfaces
- Filter settings
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-014
Exact manifest acceptance criterion
- Updates labels, translations, status and order atomically.
Demo safety boundary
Accept only the five known filter IDs.
catalog.pickup.upsertCreate or update pickup locationCatalog, SKUs and fulfillment
catalog.pickup.upsertCreate or update pickup location- Command ID
CMD-CAT-PICKUP-UPSERT- Request fields
- pickupLocation
- Changed entities
- pickupLocations · timeSlots · audit
- UI surfaces
- Pickup manager
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-015
Exact manifest acceptance criterion
- Upserts location and time slots atomically.
Demo safety boundary
Use fictitious bounded addresses and schedules.
catalog.pickup.deleteDelete pickup locationCatalog, SKUs and fulfillment
catalog.pickup.deleteDelete pickup location- Command ID
CMD-CAT-PICKUP-DELETE- Request fields
- pickupLocationId
- Changed entities
- pickupLocations · products · audit
- UI surfaces
- Pickup delete confirmation
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-015
Exact manifest acceptance criterion
- Deletes the location and its mappings without touching order snapshots.
Demo safety boundary
Remove session-owned product mappings consistently.
catalog.fulfillment.updateUpdate courier delivery availabilityCatalog, SKUs and fulfillment
catalog.fulfillment.updateUpdate courier delivery availability- Command ID
CMD-CAT-FULFILLMENT- Request fields
- courierDeliveryEnabled
- Changed entities
- catalogSettings · audit
- UI surfaces
- Courier toggle
- Routes
PATCH /api/admin/catalog- Covers capabilities
- ACC-CAT-015
Exact manifest acceptance criterion
- The toggle updates checkout/API projections and audit.
Demo safety boundary
No logistics integration is called.
order.updateUpdate orderOrders and fulfillment operations
order.updateUpdate order- Command ID
CMD-ORD-UPDATE- Request fields
- orderId · patch
- Changed entities
- orders · audit · analytics
- UI surfaces
- Order card
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-ORD-003ACC-ORD-004
Exact manifest acceptance criterion
- Updates lifecycle or support fields and derived analytics.
Demo safety boundary
Validate exact status and priority enums and bounded notes.
order.batch-updateBatch update ordersOrders and fulfillment operations
order.batch-updateBatch update orders- Command ID
CMD-ORD-BATCH- Request fields
- orderPatches
- Changed entities
- orders · audit · analytics
- UI surfaces
- Bulk order command panel
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-ORD-008
Exact manifest acceptance criterion
- Applies all selected order patches atomically.
Demo safety boundary
Cap selection at 500.
order.archive-batchArchive or restore ordersOrders and fulfillment operations
order.archive-batchArchive or restore orders- Command ID
CMD-ORD-ARCHIVE- Request fields
- orderIds · archived
- Changed entities
- orders · audit
- UI surfaces
- Archive/restore confirmation
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-ORD-001ACC-ORD-008
Exact manifest acceptance criterion
- Moves selected orders between active and archive atomically.
Demo safety boundary
Cap selection and preserve immutable order content.
contact.updateUpdate contact statusSubscriptions and customer requests
contact.updateUpdate contact status- Command ID
CMD-COM-CONTACT-UPDATE- Request fields
- contactRequestId · status
- Changed entities
- contactRequests · audit
- UI surfaces
- Contact card
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-COM-004
Exact manifest acceptance criterion
- Updates one exact contact state and audit event.
Demo safety boundary
Only session-owned synthetic contacts can change.
contact.batch-updateBatch update contactsSubscriptions and customer requests
contact.batch-updateBatch update contacts- Command ID
CMD-COM-CONTACT-BATCH- Request fields
- contactRequestPatches
- Changed entities
- contactRequests · audit
- UI surfaces
- Bulk contact command panel
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-COM-004
Exact manifest acceptance criterion
- Applies all selected contact state changes atomically.
Demo safety boundary
Cap selection at 500.
contact.replyQueue contact replySubscriptions and customer requests
contact.replyQueue contact reply- Command ID
CMD-COM-CONTACT-REPLY- Request fields
- contactRequestId · subject · message · idempotencyKey
- Changed entities
- contactRequests · outbox · idempotency · audit
- UI surfaces
- Reply composer
- Routes
POST /api/admin/operations- Covers capabilities
- ACC-COM-006ACC-COM-008
Exact manifest acceptance criterion
- Creates one replay-safe reply and marks the request processed.
Demo safety boundary
Persist sandbox outbox only; never send SMTP.
review.createCreate reviewReviews and moderation
review.createCreate review- Command ID
CMD-REV-CREATE- Request fields
- review
- Changed entities
- reviews · audit
- UI surfaces
- Review create mode
- Routes
POST /api/admin/operations- Covers capabilities
- ACC-REV-001ACC-REV-003ACC-REV-004
Exact manifest acceptance criterion
- Creates a full valid home or product review.
Demo safety boundary
Cap reviews and validate delivered target references.
review.updateUpdate reviewReviews and moderation
review.updateUpdate review- Command ID
CMD-REV-UPDATE- Request fields
- reviewId · patch
- Changed entities
- reviews · audit · analytics
- UI surfaces
- Review editor · Moderation card
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-REV-003ACC-REV-007
Exact manifest acceptance criterion
- Updates any full review field and derived moderation metrics.
Demo safety boundary
Validate rating, body and references.
review.deleteDelete reviewReviews and moderation
review.deleteDelete review- Command ID
CMD-REV-DELETE- Request fields
- reviewId
- Changed entities
- reviews · uploads · audit
- UI surfaces
- Review delete confirmation
- Routes
DELETE /api/admin/operations- Covers capabilities
- ACC-REV-003
Exact manifest acceptance criterion
- Deletes one review and updates summaries.
Demo safety boundary
Clean only unreferenced session-owned media.
review.batch-updateBatch update reviewsReviews and moderation
review.batch-updateBatch update reviews- Command ID
CMD-REV-BATCH- Request fields
- reviewPatches
- Changed entities
- reviews · audit · analytics
- UI surfaces
- Bulk moderation · Save all
- Routes
PATCH /api/admin/operations- Covers capabilities
- ACC-REV-007
Exact manifest acceptance criterion
- Atomically publishes, hides or saves selected review drafts.
Demo safety boundary
Cap selection at 500.
content.entry.createCreate content entryContent and marketing placements
content.entry.createCreate content entry- Command ID
CMD-CNT-ENTRY-CREATE- Request fields
- entry
- Changed entities
- contentEntries · audit
- UI surfaces
- Content composer
- Routes
POST /api/admin/content- Covers capabilities
- ACC-CNT-003
Exact manifest acceptance criterion
- Creates a positioned scoped entry.
Demo safety boundary
Text-only bounded content.
content.entry.updateUpdate content entryContent and marketing placements
content.entry.updateUpdate content entry- Command ID
CMD-CNT-ENTRY-UPDATE- Request fields
- entryId · patch
- Changed entities
- contentEntries · audit
- UI surfaces
- Content editor
- Routes
PATCH /api/admin/content- Covers capabilities
- ACC-CNT-003
Exact manifest acceptance criterion
- Updates entry fields and public projection under status rules.
Demo safety boundary
Reject HTML/script input and unknown fields.
content.entry.deleteDelete content entryContent and marketing placements
content.entry.deleteDelete content entry- Command ID
CMD-CNT-ENTRY-DELETE- Request fields
- entryId
- Changed entities
- contentEntries · audit
- UI surfaces
- Content delete confirmation
- Routes
DELETE /api/admin/content- Covers capabilities
- ACC-CNT-003
Exact manifest acceptance criterion
- Deletes one entry and updates public projection.
Demo safety boundary
Delete only session-owned content.
content.entry.batch-updateBatch update content entriesContent and marketing placements
content.entry.batch-updateBatch update content entries- Command ID
CMD-CNT-ENTRY-BATCH- Request fields
- contentPatches
- Changed entities
- contentEntries · audit
- UI surfaces
- Save texts
- Routes
PATCH /api/admin/content- Covers capabilities
- ACC-CNT-004
Exact manifest acceptance criterion
- Commits all text drafts atomically.
Demo safety boundary
Cap batch at 500 and total state bytes.
marketing.block.createCreate marketing blockContent and marketing placements
marketing.block.createCreate marketing block- Command ID
CMD-MKT-BLOCK-CREATE- Request fields
- marketingBlock
- Changed entities
- marketingBlocks · audit
- UI surfaces
- Marketing editor
- Routes
POST /api/admin/content- Covers capabilities
- ACC-CNT-005ACC-CNT-006
Exact manifest acceptance criterion
- Creates one complete marketing placement.
Demo safety boundary
Validate links, text and upload ownership.
marketing.block.updateUpdate marketing blockContent and marketing placements
marketing.block.updateUpdate marketing block- Command ID
CMD-MKT-BLOCK-UPDATE- Request fields
- blockId · patch
- Changed entities
- marketingBlocks · audit
- UI surfaces
- Marketing editor
- Routes
PATCH /api/admin/content- Covers capabilities
- ACC-CNT-005ACC-CNT-006
Exact manifest acceptance criterion
- Updates any validated marketing field and preview.
Demo safety boundary
Validate links, text and upload ownership.
marketing.block.deleteDelete marketing blockContent and marketing placements
marketing.block.deleteDelete marketing block- Command ID
CMD-MKT-BLOCK-DELETE- Request fields
- blockId
- Changed entities
- marketingBlocks · uploads · audit
- UI surfaces
- Marketing delete confirmation
- Routes
DELETE /api/admin/content- Covers capabilities
- ACC-CNT-005
Exact manifest acceptance criterion
- Deletes one block and removes its public projection.
Demo safety boundary
Schedule only session-owned orphan media cleanup.
marketing.block.batch-updateBatch update marketing blocksContent and marketing placements
marketing.block.batch-updateBatch update marketing blocks- Command ID
CMD-MKT-BLOCK-BATCH- Request fields
- marketingBlockPatches
- Changed entities
- marketingBlocks · audit
- UI surfaces
- Save marketing
- Routes
PATCH /api/admin/content- Covers capabilities
- ACC-CNT-007
Exact manifest acceptance criterion
- Commits all marketing drafts atomically.
Demo safety boundary
Cap batch at 200.
email.campaign.previewBuild campaign previewEmail campaigns and outbox
email.campaign.previewBuild campaign preview- Command ID
CMD-EML-PREVIEW- Request fields
- audience · content
- Changed entities
- preview fingerprint
- UI surfaces
- Campaign preview
- Routes
POST /api/admin/email-campaigns- Covers capabilities
- ACC-EML-005ACC-EML-006
Exact manifest acceptance criterion
- Returns current send-readiness and placeholder fields.
Demo safety boundary
Render escaped inert HTML/text without delivery.
email.campaign.enqueueEnqueue sandbox campaignEmail campaigns and outbox
email.campaign.enqueueEnqueue sandbox campaign- Command ID
CMD-EML-ENQUEUE- Request fields
- audience · selection · content · idempotencyKey
- Changed entities
- campaigns · outbox · idempotency · audit
- UI surfaces
- Campaign composer
- Routes
POST /api/admin/email-campaigns- Covers capabilities
- ACC-EML-004ACC-EML-008ACC-EML-009
Exact manifest acceptance criterion
- Creates or replays one campaign with an exact audience snapshot.
Demo safety boundary
Never open SMTP; persist deterministic sandbox preparation only.
email.transport.verifyVerify sandbox transportEmail campaigns and outbox
email.transport.verifyVerify sandbox transport- Command ID
CMD-EML-VERIFY- Request fields
- operation
- Changed entities
- emailDiagnostics · audit
- UI surfaces
- Transport diagnostics
- Routes
POST /api/admin/email-diagnostics- Covers capabilities
- ACC-EML-002
Exact manifest acceptance criterion
- Persists a rate-limited normalized verification result.
Demo safety boundary
Perform no network call; verify internal no-delivery transport policy.
session.revokeRevoke administrative sessionsAudit and administrative sessions
session.revokeRevoke administrative sessions- Command ID
CMD-SEC-SESSIONS-REVOKE- Request fields
- scope
- Changed entities
- adminSessions · audit
- UI surfaces
- Session manager confirmation
- Routes
PATCH /api/admin/sessions- Covers capabilities
- ACC-AUD-006
Exact manifest acceptance criterion
- Revoke others preserves current; revoke all ends it.
Demo safety boundary
Affect only current workspace sessions and clear cookie for all scope.
upload.createCreate session-owned image uploadCatalog, SKUs and fulfillment
upload.createCreate session-owned image upload- Command ID
CMD-UPLOAD-CREATE- Request fields
- multipart images
- Changed entities
- uploads · audit · R2 object
- UI surfaces
- Product/review/marketing/campaign upload
- Routes
POST /api/admin/uploads- Covers capabilities
- ACC-CAT-006ACC-REV-005ACC-CNT-007ACC-EML-012
Exact manifest acceptance criterion
- Stores and returns only session-owned safe image references.
Demo safety boundary
At most 12 files, 4 MiB per file, 16 MiB per session and 20 MiB per request; magic bytes are checked, SVG is denied, keys are random and expired objects are cleaned up.
upload.deleteDelete session-owned image uploadCatalog, SKUs and fulfillment
upload.deleteDelete session-owned image upload- Command ID
CMD-UPLOAD-DELETE- Request fields
- fileName
- Changed entities
- uploads · audit · R2 object
- UI surfaces
- Remove image
- Routes
DELETE /api/admin/uploads- Covers capabilities
- ACC-CAT-006ACC-REV-005ACC-CNT-007ACC-EML-012
Exact manifest acceptance criterion
- Deletes an unreferenced owned object and metadata; a cross-session file name returns not found.
Demo safety boundary
Ownership check is mandatory and referenced objects cannot be deleted silently.
HTTP / 54 ROUTES
Every server endpoint, mapped
Only /api/v1 is a stable external contract. Other routes serve the interface and system processes and may evolve with them.GET
/api/v1Stable API v1stable external contract
Discover the API version, authentication, and resources.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/v1/healthStable API v1stable external contract
Minimal process health check without internal details.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/v1/openapi.jsonStable API v1stable external contract
Machine-readable OpenAPI 3.1 document.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/v1/catalogStable API v1stable external contract
Public catalog with filtering, sorting, and pagination.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/v1/contentStable API v1stable external contract
Published content entries, optionally filtered by scope.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/v1/searchStable API v1stable external contract
Search over the public catalog projection.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
POST
/api/v1/ordersStable API v1stable external contract
Idempotent order creation with reservation.
How to connect it
Open API v1 recipesCall it from a server-side integration or the SDK with the smallest scope. OpenAPI 3.1 defines the request and response schema.
GET
/api/catalogStorefront and customer flowsservice route
Public catalog projection.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/catalog/productsStorefront and customer flowsservice route
Batch product lookup.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/analytics/eventsStorefront and customer flowsservice route
Ingest allow-listed first-party events after explicit consent without IP, User-Agent, or a full referrer.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/contactStorefront and customer flowsservice route
Create a customer request.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GET
/api/contentStorefront and customer flowsservice route
Public content delivery.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GET
/api/localeStorefront and customer flowsservice route
Current interface locale.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/newsletterStorefront and customer flowsservice route
Double opt-in subscription.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/newsletter/one-clickStorefront and customer flowsservice route
One-click unsubscribe.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/order-accessStorefront and customer flowsservice route
Issue bounded order access.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GETPOST
/api/ordersStorefront and customer flowsservice route
Read and create an order.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GETPOST
/api/orders/:orderId/paymentStorefront and customer flowsservice route
Payment status and hosted payment start.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/orders/:orderId/payment/syncStorefront and customer flowsservice route
Reconcile a payment with the provider.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GET
/api/searchStorefront and customer flowsservice route
Storefront search.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
GET
/api/uploads/products/:fileStorefront and customer flowsservice route
Serve authorized product media.
How to connect it
Use it as the storefront's same-origin backend. Define a public adapter and threat model before moving it behind another frontend.
POST
/api/account/feedbackCustomer accountservice route
Authenticated customer request.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
PATCH
/api/account/profileCustomer accountservice route
Update the customer profile.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
POST
/api/account/reviewsCustomer accountservice route
Submit an account review.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
GETPOSTDELETE
/api/account/sessionCustomer accountservice route
Inspect, create, and end a session.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
POST
/api/account/sessionsCustomer accountservice route
Manage other sessions.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
POSTDELETE
/api/account/yandexCustomer accountservice route
Connect and disconnect Yandex ID.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
GET
/api/account/yandex/callbackCustomer accountservice route
Yandex ID OAuth callback.
How to connect it
Call it only inside the customer cookie session with CSRF/origin protection. Do not expose it as public API without a separate contract.
GET
/api/admin/analytics/trafficInternal Studio surfaceservice route
Privacy-first traffic aggregates for 7, 30, or 90 days and the matching previous period.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOSTPATCHDELETE
/api/admin/catalogInternal Studio surfaceservice route
Catalog snapshot and mutations.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/catalog/exportInternal Studio surfaceservice route
Catalog and stock exports.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/catalog/metadataInternal Studio surfaceservice route
Category and filter metadata.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/catalog/productsInternal Studio surfaceservice route
Filterable product list.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/catalog/products/:productIdInternal Studio surfaceservice route
Complete product record.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/catalog/sku-registryInternal Studio surfaceservice route
Row-level SKU registry with filters, sorting, and cursor pagination.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOSTPATCHDELETE
/api/admin/contentInternal Studio surfaceservice route
Content and marketing placements.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOST
/api/admin/email-campaignsInternal Studio surfaceservice route
Campaign audiences, previews, enqueue, and monitoring.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/email-diagnosticsInternal Studio surfaceservice route
Safe email transport diagnostics.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOSTPATCHDELETE
/api/admin/operationsInternal Studio surfaceservice route
Orders, contacts, reviews, and audit operations.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/operations/exportInternal Studio surfaceservice route
Server-side operations CSV exports.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/operations/historyInternal Studio surfaceservice route
Cursor-based operations history.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOST
/api/admin/paymentsInternal Studio surfaceservice route
Payment list and compatibility action endpoint.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GET
/api/admin/payments/:paymentIdInternal Studio surfaceservice route
Payment details.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/payments/:paymentId/cancelInternal Studio surfaceservice route
Idempotent payment cancellation.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/payments/:paymentId/captureInternal Studio surfaceservice route
Capture a two-stage payment.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/payments/:paymentId/refundsInternal Studio surfaceservice route
Full or partial refund.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/admin/payments/:paymentId/syncInternal Studio surfaceservice route
Reconcile status with YooKassa.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POSTDELETE
/api/admin/sessionInternal Studio surfaceservice route
Token/TOTP sign-in and sign-out.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPATCH
/api/admin/sessionsInternal Studio surfaceservice route
List and revoke administrative sessions.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
GETPOSTDELETE
/api/admin/uploadsInternal Studio surfaceservice route
Upload, list, and delete media.
How to connect it
This route serves the admin panel and requires an administrative session. Give external clients /api/v1 or a dedicated adapter.
POST
/api/webhooks/payments/yookassaIntegrations and operationsservice route
YooKassa signal followed by mandatory provider API verification.
How to connect it
Connect only a trusted provider, load balancer, orchestrator, or monitoring probe through a network allow-list.
GET
/healthIntegrations and operationsservice route
Process liveness.
How to connect it
Connect only a trusted provider, load balancer, orchestrator, or monitoring probe through a network allow-list.
GET
/health/readyIntegrations and operationsservice route
Application and dependency readiness.
How to connect it
Connect only a trusted provider, load balancer, orchestrator, or monitoring probe through a network allow-list.
GET
/humans.txtIntegrations and operationsservice route
Public delivery information.
How to connect it
Connect only a trusted provider, load balancer, orchestrator, or monitoring probe through a network allow-list.
NEXT STEP