Resolved vs. raw reads
Reads come in two shapes:- Resolved.
GET /documents/sections/{sectionID}andGET /documents/templates/{templateID}return the resource resolved — all inheritance applied, sections fully expanded on templates. This is the ready-to-consume shape that will be used at generation time. - Raw.
GET .../versions/{versionID}andLIST .../versionsreturn the version raw — only the values this version explicitly owns, plusinheritFromIdand (for templates)sectionIdreferences. Use this when you need to distinguish inherited fields from fields the resource explicitly overrides.
Soft-delete and inheritance guards
DELETE on a section or template returns 409 Conflict if any other section or template inherits from it. Resolve the dependency first — delete or re-parent the inheriting resources — before retrying the delete.
Deletion is not Breaking. After deletion,
LIST and GET no longer return the resource, but document generation still works.
We opted for this behaviour to safeguard existing deployments from unintentional disruptions.Managing sections
PATCH /documents/sections/{sectionID} only updates section-level metadata. To change the prompts or output schema, create a new version and publish it — see Versioning.Managing templates
PATCH /documents/templates/{templateID} only updates template-level metadata. To change the prompt or section composition, create a new version and publish it — see Versioning.Discovery: filtering and listing
BothGET /documents/sections and GET /documents/templates accept the same set of query parameters. Use any combination — they’re additive.
Empty
languages, regions, or specialties means “no tweaks for that dimension” — the resource is generic along that axis. The fields are arrays but each one is optional and empty by default.Label filtering semantics
When you repeat thelabel query parameter, the filtering logic is:
- Multiple values for the same key → OR. A resource matches if it carries any of the given values for that key.
- Multiple different keys → AND. A resource must carry at least one value for every key you supply.
Example — OR within a key, AND across keys
customer:acme or customer:beta, and also tagged with department:cardiology.
The label query language is minimal today — flat
key:value containment with AND/OR semantics. Richer query capabilities (negation, wildcards, scoped path expressions) are on the roadmap.