Last updated Jun 14, 2026

Templates

Matter exposes a template registry as the surface through which document templates are discovered and used. This page describes the surface — the endpoints, the schema, and the architectural commitments that shape how templates plug into the rest of the API.

The specific templates Matter ships are a separate concern, tracked independently of this surface. The registry can hold zero templates today and catalog hundreds tomorrow without changing the API contract.

Every template is Matter-authored. There is no third-party template ingestion — no Common Paper, Bonterms, NVCA, or other open-licensed sources. The catalog is single-provenance by design, which keeps the attribution surface trivial and the legal-review pipeline coherent.

The registry surface

• GET /v1/templates — list templates filtered by kind (the Document.type value the template produces), category, availability (defaults to ga), and attachable_to (parent template_id, for picking attachment children like Pro Rata Side Letters).
• GET /v1/templates/{template_id} — retrieve a single template's full metadata, including its Cover Page field schema (when applicable).
• template_id is conventionally matter:<kind>[:<variant>]:<version> — the format is descriptive, not structurally enforced. Clients should treat the full id as opaque and filter on the structured kind, category, and version fields.

Multiple templates may share the same kind. SAFE alone has variants spanning post-money × {cap-only, discount-only, cap-and-discount, MFN}; each variant is its own row with its own template_id and Cover Page field schema, all carrying kind: safe. The picker is the natural shape that follows: GET /v1/templates?kind=safe returns the variant rows and the client renders a chooser.

The Cover Page model

Matter is intentionally not a contract-negotiation platform. The product surface is built around the Cover Page model: a small, well-defined negotiable surface plus an immutable contract body.

1. Standard Terms are the contract body — versioned, hosted at a permanent URL, never edited per deal.
2. Cover Page is a short document populated with the deal-specific fields (parties, fees, term, key options). It incorporates the Standard Terms by reference. Both parties sign the Cover Page; the combined artifact is the executed Agreement.

The negotiation surface is the Cover Page — typically a handful of fields, often nothing more than parties, fees, and term. By constraining what is negotiable to a small, well-defined surface, the Cover Page model avoids the redline-everything pattern that makes traditional contracting slow.

On the Document resource, the Cover Page model is expressed via:

• template_id — identifies the Cover Page format.
• cover_page_fields — the populated negotiable values, validated against Template.cover_page_field_schema.
• standard_terms_template_id — pointer to the immutable Standard Terms version this Cover Page incorporates by reference.

These fields are reserved on the schema today; whether a given template uses them is determined per-template via cover_page_field_schema (null for templates that derive every variable from entity state — bylaws, charters, action of incorporator, board consents).

Document provenance

Documents arrive in the system through three distinct paths. The Document.provenance enum classifies which one — and is the source of truth for whether template_id and template_version are populated:

• matter_generated — Matter rendered the PDF from a Template against entity state. This is the bulk of the system: SAFEs, FSPAs, formation packets, board consents, dissolution cascades. template_id and template_version are required and immutable for the life of the Document.
• counterpart_received — a third party produced the PDF and Matter is just storing it. State-issued certificates (Certificate of Incorporation as returned by the Secretary of State), EIN acknowledgement letters from the IRS, mail scans, identification images. The Document still has a typed Document.type, but template_id is null because Matter did not render the artifact.
• user_uploaded — caller uploaded an ad-hoc file: a custom-typed contract that doesn't fit a template, an out-of-band amendment, or a one-off attachment. template_id is null.

The cross-field invariants are enforced at write time:

• provenance == matter_generated ⇒ template_id != null and template_version != null.
• provenance != matter_generated ⇒ template_id == null and template_version == null.

Surface provenance in your audit UI alongside (template_id, template_version) so reviewers can answer both "which form did we use?" and "did Matter make this, or did we receive it?" in the same glance.

Versioning and deprecation

Template versions are immutable. The (template_id, template_version) pair on a Document is a permanent pointer — re-rendering a Document against a newer template version produces a new pair.

• template_version format is a string. Date-coded (2026-04-26) is the convention for legal templates, since they evolve when counsel updates them rather than on engineering release cadences. Semver (1.2.0) is permitted for engineering-driven artifacts (e.g. cap-table snapshots whose renderer schema changes). Both formats remain valid forever; clients treat the value as opaque.

• Template.availability carries the lifecycle state:

  State	New generations?	Existing Documents	UX
  preview	yes (low-tier tokens)	n/a	hidden from default listTemplates; opt-in via the query param
  ga	yes	active	default listing
  deprecated	yes (warning)	active	listed; the response carries Matter-Deprecated-Template: <successor_template_id>
  retired	no — 409 template_retired	active forever	hidden from listings; only retrievable by id

• Template.successor_template_id is populated on deprecated and retired rows; clients should switch to the successor on the next regeneration cycle. A Document.template_id pointing at a retired template stays valid forever — the Document is the historical artifact and its provenance pointer is permanent.

What Matter does and does not do

Matter is the standardized-template tier. The product makes baseline legal artifacts trivial to generate, sign, and track — formation packets, SAFEs, mutual NDAs, SaaS subscription agreements, and the like — by constraining each artifact to a small Cover Page negotiation surface sitting on top of an immutable Standard Terms body.

Matter is not a custom-legal AI platform. Heavily-negotiated commercial deals, M&A definitive agreements, complex licensing structures, and anything where the Standard Terms themselves need redlining are out of scope.

The architectural commitments above (registry endpoints, Cover Page fields, provenance classification, versioning lifecycle) operationalize this division: Matter's surface rewards the standardized case and stays out of the way of the heavily-negotiated tail.

Status today

The registry surface ships in the spec. The v1 catalog ships 22 governance-category templates covering the board-and-stockholder consent surface; other categories (formation, financing, commercial, tax) ingest through separate workstreams.

v1 governance catalog

The 22 v1 templates are the source-of-truth catalog block (x-matter-template-catalog) at the top level of apps/docs/api-reference/openapi.yaml. Filter row counts:

Two of the 22 (matter:board_consent:general:2026-04-26 and matter:written_consent:general:2026-04-26) carry a non-null cover_page_field_schema for caller-supplied recitals and resolved clauses — these are the deliberate exceptions to the "board consents derive from entity state" rule, and absorb any Resolution.kind that no specialized template covers. The other 20 derive substance from the linked resource (Round, EquityPlan, CorporateTransaction, etc.) and entity state.

What still ships empty

• Other category values (formation, financing, commercial, tax) return zero rows from listTemplates until their respective ingestion workstreams land.
• generateDocument calls that pass a template_id outside the v1 governance catalog are rejected.
• Documents with provenance: counterpart_received (state certificate filings, EIN acknowledgements, mail scans) and provenance: user_uploaded (custom-typed contracts) work today via the upload path with template_id: null.
• The Document.type enum extension (commercial categories: csa, mnda, psa, pilot_agreement, design_partner_agreement, software_license, marketplace_terms, reseller_agreement, end_user_agreement, online_cloud_terms; hiring categories: independent_contractor_agreement, advisor_agreement, employment_agreement, offer_letter, ciiaa) is live and usable for provenance: user_uploaded documents — categorization works without templates being shipped.