> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corti.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Customize Templates & Sections — Cookbook
> Best-practice customiztion recipes from simplest to most advanced — when to use Corti Standards, when to inherit via inheritFromId, and when to apply runtime overrides at /documents
Beta
Recipes use the new `/documents/sections`, `/documents/templates` and `POST /documents` endpoints. See [Create a Section](/textgen/section-creation), [Create a Template](/textgen/template-creation), [Guided Synthesis](/textgen/documents-guided-synthesis) for the underlying mechanics.
## The three levers
There are exactly three customization levers in the new API. The art is picking the right one — or stacking them.
| Lever | Where | Persistence | Use when |
| :------------------------------- | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------- |
| **1. Use as-is** | Reference an existing section or template by `id` | n/a | The resource already does what you need |
| **2. Inherit (`inheritFromId`)** | `POST /documents/sections` or `POST /documents/templates` | Persistent, but **not detached**. New, versioned resource that resolves the parent's published version at request time — so it auto-tracks upstream updates on every field you didn't override. | Stable, governed customization for an organization, customer or specialty |
| **3. Runtime overrides** | `POST /documents` (Paths 2 & 3) | Ephemeral. A drift-proof auto-generated template aggregate is persisted for traceability (**30-day retention** — see [Guided Synthesis](/textgen/documents-guided-synthesis#auto-generated-template-aggregates-30-day-retention)); the original base is untouched. | Per-call, per-user, per-encounter tweaks — including end-user UI customization |
**Rule of thumb.** If the same tweak applies for *every call from this customer*, create an inheriting resource. If it varies *between calls*, override at runtime.
## Picking a lever — decision flow
Walk the three questions below to land on the recipe that fits your scenario.
```mermaid theme={null}
flowchart TD
Q1{Need to change anything?}
Q1 -- No --> R1["Recipe 1
Use a Corti Standard as-is"]
Q1 -- Yes --> Q2{Does the change apply
to every call?}
Q2 -- "No, varies per call or user" --> R357["Runtime overrides
Recipe 3, 5, or 7"]
Q2 -- Yes --> Q3{Many customers or departments
need their own twist?}
Q3 -- No --> R24["Recipe 2 inherit from a Standard
or Recipe 4 author your own"]
Q3 -- Yes --> R6["Recipe 6
Inherit from your own"]
classDef decision fill:#FFF7E0,stroke:#D8A11C,color:#5B4500
classDef recipe fill:#E8F1FF,stroke:#3A6BD8,color:#13325F
class Q1,Q2,Q3 decision
class R1,R357,R24,R6 recipe
click R1 "/textgen/customization-cookbook/recipe-1-corti-standard-as-is" "Recipe 1"
click R6 "/textgen/customization-cookbook/recipe-6-inherit-your-own" "Recipe 6"
```
Boxes for single-recipe outcomes (Recipe 1, Recipe 6) are clickable and take you directly to the recipe page. The two multi-recipe outcomes branch further; see the recipe cards below to choose between **Recipe 2 vs 4** (inherit from a Corti Standard vs. author your own) or among **Recipe 3, 5, 7** (which runtime-override stack fits your base).
## How end-users access your customizations
The recipes above cover **what** to customize. There's an orthogonal question about **who can use which customization** — driven by your integration model. Walk this second flow once for your integration and pair the answer with the recipe you picked above.
```mermaid theme={null}
flowchart TD
A1{Integration model?}
A1 -- "Embedded Corti Assistant" --> EA["Console Customers
Assign templates and sections to
groups of end-users via Corti Console.
Assignment enforced by Console."]
A1 -- "Pure API" --> A2{Multi-tenant
via one API client?}
A2 -- "No — one project per customer" --> SIMPLE["Permissions follow the project boundary.
Standard recipes apply directly."]
A2 -- "Yes — one client, many end-users" --> A3{Where do user-specific
templates live?}
A3 -- "As Corti resources" --> P1["Pattern 1 — Label-based filtering
Save as Corti templates/sections.
Tag with label userId: <uuid>.
LIST with the label as filter.
Labels enable discovery,
not permission enforcement."]
A3 -- "On your side" --> P2["Pattern 2 — Your-side persistence
Persist user customizations in your DB.
Parse into a dynamicTemplate request
at generation time.
You own access control end-to-end."]
classDef decision fill:#FFF7E0,stroke:#D8A11C,color:#5B4500
classDef outcome fill:#E8F1FF,stroke:#3A6BD8,color:#13325F
class A1,A2,A3 decision
class EA,SIMPLE,P1,P2 outcome
```
### Embedded Corti Assistant — use Console **Customers**
When you ship the embedded Corti Assistant, lean on Corti Console's **Customers** facility to assign templates and sections to groups of end-users. Console enforces the assignment; your integration code doesn't need its own permission layer. This is the recommended path whenever the Assistant is in play.
### Pure API integration — you own access control
When you integrate directly via the API, **you** decide which end-user can use which template. If you've spun up one project per customer the project boundary already segregates them — standard recipes apply directly. The more interesting case is **one API client serving many end-users**, where you've got two patterns to choose between.
Save each user's template / section as a Corti resource and tag it with a label like `{ "key": "userId", "value": "" }`. At runtime, [`LIST /documents/templates?label=userId:`](/textgen/management-discoverability#discovery-filtering--listing) returns only that user's resources.
**Be aware:** labels are a *discovery & filtering* mechanism, not access control. Any caller with project credentials can read any label-tagged resource. Use this when discoverability and a uniform Corti resource model matter (e.g. a single `LIST` powering a template picker).
Persist user templates and overrides in your own database. At generation time, parse them into a [`dynamicTemplate`](/textgen/documents-guided-synthesis/path-4-dynamic) request — sections and template defined fully inline in the `POST /documents` body.
Nothing user-specific lives on Corti's side, so you own the permission model, audit trail, and isolation guarantees end-to-end. Use this when you need real access enforcement, or when per-user customizations are too lightweight to warrant a persisted Corti resource each.
The two patterns aren't mutually exclusive. A common shape is **Pattern 1 for stable per-customer templates** (governed, reusable) **+ Pattern 2 for ephemeral per-user tweaks** (parsed into `dynamicTemplate` overrides at request time).
## Recipes, simple → advanced
Each recipe is its own page so you can land directly on the pattern that matches your need.
Reference a curated Corti template by UUID. Lightest, fastest, no side-effects. Ideal for production traffic.
Fork a Corti Standard via `inheritFromId`. Persistent, versioned, auto-tracks upstream improvements on un-overridden fields.
Reference a Standard at runtime with `templateRef.overrides`. End-user-style tweaks (presets or free-prompt) without persisting anything.
Stable, governed sections + templates owned by your project. Versioned and publishable; full control over prompts and schema.
Pair your stable templates with per-call runtime overrides — last-mile end-user control without per-user resource sprawl.
Keep one canonical section + customer/department-specific inheriting variants. Canonical improvements propagate everywhere.
Canonical + customer inheritance + per-call runtime overrides. The most operational recipe, for multi-customer SaaS.
Working with EHR SmartPhrase tokens? See [Including EHR SmartPhrase Tokens](/textgen/smartphrase-tokens) for the prompting pattern.
## Override semantics — the cheat sheet
Whenever you apply an override (on an inheriting resource via `inheritFromId` **or** at `POST /documents` runtime), these rules govern what merges:
| Field | Merge behavior |
| :--------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- |
| `instructions.contentPrompt`, `writingStylePrompt`, `miscPrompt` | **Per-field partial.** Any field you omit is inherited from the parent's published version. |
| `outputSchema` | **Wholesale replacement.** Whatever you submit fully replaces the parent schema. Partial schemas are not merged. |
| `title` / section heading | **Wholesale replacement** when provided; inherited when omitted. |
| Section composition (`sections[]` on a template) | **Wholesale replacement** when provided on an inheriting template; inherited when omitted. |
The same per-field-vs-wholesale split applies whether you're inheriting from a section (`POST /documents/sections` with `inheritFromId`), inheriting from a template (`POST /documents/templates` with `inheritFromId`), or applying runtime overrides on `POST /documents`. Once you know it for one place, you know it for all three.
## When **not** to use these recipes
* **One-off prototypes.** Skip Recipes 4–7 entirely and use `POST /documents` Path 4 (`dynamicTemplate`) — fully inline, no resources to manage. See [Guided Synthesis — Path 4](/textgen/documents-guided-synthesis/path-4-dynamic).
* **A single document built from a few standard sections.** Skip the template entirely and use Path 3 (`assemblyTemplate`) — assemble sections at request time. See [Guided Synthesis — Path 3](/textgen/documents-guided-synthesis/path-3-assembly).
## Related
Author sections and create inheriting variants via `inheritFromId`.
Schema patterns for the `outputSchema` choices in these recipes.
Compose sections into templates; create inheriting templates via `inheritFromId`.
Where runtime overrides happen — Paths 2, 3 and 4 of `POST /documents`.