Repository navigation
Create from…: POST /api/materialize plumbing + domain model #11
Description
Part of #10 — "Create from…" (materialize) — turn messages, lists, rows and documents into new lists/documents/posts
Shared foundation for the other Create-from sub-issues.
- Capture the real
POST /api/materializerequest/response shapes against the live API before
writing DTOs (the spec only typessourceloosely). - Model the four destinations (
To List,To Doc,To List & Doc,To Message) and the four
source kinds (message(s), list, rows, document/selection) as a single domain type. - Decide the module home — a small shared
:feature:materialize, or a:core:helper consumed
by messages/lists/documents. It is called from three feature modules, so it must not live
inside any one of them. - Subscriber gating: the menu opens for everyone; confirming on a free account routes to the
existing subscription-required handling.
Tests: MockWebServer round-trip per destination; free-account confirm → upsell, no write.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Activity
Adron commentedon Sep 16, 2026
Implemented in #100 (branch
issue/11-materialize-plumbing). Closing here — review and any follow-up happens on the PR.Module home decided:
:core:materialize— it is called from three feature modules and no feature module in this repo depends on another, so a shared module was the only correct answer.Two corrections to this issue's text, both load-bearing for #12–#16:
source.kind, notsource.type.documentanddocElementsare separate.Both come from
https://interlinedlist.com/help/api/create-from, the human-written API reference that documents the real{ target, source, listConfig?, docConfig?, messageConfig? }shape.target: "message"returns a draft and writes nothing, which is encoded in the type — that is what #16 needs.One question for you, carried into the PR: is
target: "message"subscriber-gated? The two docs disagree — the API reference says "Subscriber only: yes" for the whole endpoint, while/help/create-fromsays "To Message posts through the normal composer… posting is free". It is resolved defensively for now (no client-side pre-block on the message target, but a server 403 still routes to the upsell, so no write ever occurs on a free account). Only a free-tier account could settle it and the test account is a subscriber.merge: #11 :core:materialize plumbing (PR #100)