4349 lines, 9 numbered sections per the Backend Finalization Sprint spec: Bootstrap, Endpoint Framework, CRUD Contracts (~102 endpoints across 20 domains), Authentication (spliced from AUTHENTICATION.md), Security, Error Model (spliced from ERROR_CONTRACT.md), Uploads, Real Backend Implementation Guide, Backend Checklist (34 items). Everything traced to docs/context/BACKEND-AUDIT.md and actual current source - proposed (unverified) paths explicitly marked as such, everything the frontend has no opinion on marked "Requires backend decision" rather than invented. Archived the three docs this supersedes (BACKEND_API.md, AUTH.md, BACKEND_API_REMAINING_WORK.md) to docs/archive/ with pointers back to this file. AUTHENTICATION.md, ERROR_CONTRACT.md, MAINTENANCE_MODE.md kept in place as standalone companion references (their content is also inlined/cross-referenced here). ADMIN.md left untouched - it's a frontend admin-UI sprint doc, not a backend spec, no overlap. Verified via repo-wide search: no other backend/API spec docs remain outside archive/ and this canonical file.
7.6 KiB
ARCHIVED 2026-07-26. Superseded by
docs/BACKEND_INTEGRATION.md, the single canonical backend integration document. Kept for history only — do not implement against this file.
Remaining backend work (everything except auth/session)
Companion to the API-CONTRACT.md backend delivered separately (covers GET /bootstrap
transport + /users/sessions/* — done, see prior conversation). This file lists what's
still outstanding. Full request/response shapes, TypeScript
interfaces, and validation rules for every item below already exist in
docs/BACKEND_API.md — this is a prioritized
punch list with links into that spec, not a duplicate of it. Do not re-document
endpoint shapes here — edit the master spec if a shape needs to change.
Status legend (same as master spec): PLANNED = shape fully specified client-side,
served by a mock gateway today, nothing built server-side yet. FUTURE = reserved
contract only, no urgency. Bootstrap's content (branding/theme/nav values, not the
GET /bootstrap transport itself) is also still outstanding — see P0 below.
Status legend for this list
DONE = wired end-to-end on the frontend (real HTTP gateway or real call site, no mock left in the path). PLANNED = shape fully specified client-side, still served by a mock gateway, nothing wired yet. Everything below that isn't marked DONE is still open.
P0 — blocks going live at all
| # | Item | Status | Spec section |
|---|---|---|---|
| 1 | bootstrap.json real content (branding, theme, navigation, seo) — currently default stubs per backend's own note in API-CONTRACT.md |
open | §4 |
| 2 | Builder — bootstrap draft/publish/validate (GET/PUT /builder/bootstrap/draft, POST /builder/bootstrap/publish, POST /builder/bootstrap/validate) — this is how the Marketplace Builder actually saves anything |
open | §6.7 |
| 3 | Backoffice — Products CRUD + variants | open | §6.10, DTOs §7.2 |
| 4 | Backoffice — Categories CRUD (tree) | DONE — admin-categories-api.gateway.ts + admin-categories-gateway.token.ts wired, swaps on RuntimeProviderStrategyService |
§6.9, DTOs §7.1 |
| 5 | Media upload/delete/replace pipeline | open | §6.18, §10 |
P1 — needed for real order/commerce flow
| # | Item | Status | Spec section |
|---|---|---|---|
| 6 | Backoffice — Orders CRUD + status transitions | open | §6.11, state machine §8.1 |
| 7 | Backoffice — Transactions (list/detail, tied to orders) | open | §6.12 |
| 8 | Order creation — checkout calls POST /orders on payment success |
DONE — ApiService.createOrder() + CartComponent.recordOrder(), fire-and-forget alongside clearCart(), doesn't touch the frozen payment call chain |
§16.9 |
| 9 | Backoffice — Users/roles/invitations | open | §6.13 |
| 10 | Backoffice — Moderation (review + report status transitions) | open | §6.14, state machines §8.4/§8.5 |
P2 — dashboards / operational visibility
| # | Item | Status | Spec section |
|---|---|---|---|
| 11 | Backoffice — Dashboard metrics & recent activity | open | §6.15 |
| 12 | Backoffice — Monitoring (all but Health) | open | §6.16 |
| 13 | Backoffice — Analytics summary (real once orders are real) | open | §6.17 |
| 14 | Builder — Content pages / CMS | open | §6.8 |
P3 — nice-to-have, no urgency
| # | Item | Status | Spec section |
|---|---|---|---|
| 15 | Search suggestions / catalog filters | open | §6.6 |
| 16 | Cross-device wishlist/compare/saved-searches sync — backend confirmed id-only stays, added GET /items/batch?ids= for hydration. Frontend needs UserExperienceRepository redesign: id-array + local product cache hydrated via the batch endpoint, replacing today's fully-synchronous denormalized-object storage |
open (unblocked, not started) | §6.6 |
| 17 | Analytics traffic/funnels/heatmaps — needs a tracking pipeline that doesn't exist yet, not just an endpoint | open | §6.17 |
| 18 | Sitemap — dynamic generation (static baseline today) | open (server-side, no frontend action) | §6.19 |
Explicitly not in this list
- Auth / Telegram session (
GET /bootstraptransport,/users/sessions/*) — covered by backend'sAPI-CONTRACT.md, frontend wiring matches it exactly.authApiUrlenv value — fixed, now points at the same host asapiUrl(https://api.dexarmarket.ru:445) in bothenvironment.tsandenvironment.production.ts.AdminWebSessionIDheader — fixed a real bug: the interceptor only attached it to URLs containing/admin/, but every real backend path is/backoffice/*,/builder/*,/media/*— none of those matched, so every new admin call would have silently gone out with no admin auth header at all. Broadened the guard inadmin-auth-headers.interceptor.ts.telegramBotusername — still unverified againstbot.go'sstartbot().- Frontend deploy domain vs. CORS allow-list — decided: frontend and API stay on the same domain, so this is a non-issue by design rather than something to reconcile against an allow-list.
- Payments — frozen, unchanged, out of scope per §2.8.
- Storefront reads/writes (categories, items, search, cart, reviews) — already real HTTP, already working, no backend work needed. See §6.1–§6.2.
For every open item above, when implementing
Read the interface + model file cited in the linked spec section before writing the
endpoint — the shape is already fixed by the frontend gateway interface, not up for
renegotiation without a frontend change. Follow the pattern now established for Categories
(admin-categories-api.gateway.ts + admin-categories-gateway.token.ts): one *ApiGateway
class implementing the existing *Gateway interface, plus one InjectionToken factory that
picks mock vs. real off RuntimeProviderStrategyService, then switch the facade(s) to inject
the token instead of the concrete mock class. See §14 for the general pattern.