Skip to main content
Beyond create and version, sections and templates share a uniform management + discovery surface: read resolved or raw, update metadata, soft-delete with inheritance guards, and filter LIST results by language, region, specialty and label. The endpoints below detail the per-resource specifics. The semantics — resolved-vs-raw reads, soft-delete conflicts, deletion visibility, and filter query params — are shared across both resource types.

Resolved vs. raw reads

Reads come in two shapes:
  • Resolved. GET /documents/sections/{sectionID} and GET /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} and LIST .../versions return the version raw — only the values this version explicitly owns, plus inheritFromId and (for templates) sectionId references. 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

Both GET /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 the label 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
Returns templates tagged with either 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.

Listing sections

Listing templates