Skip to main content
Beta
Recipes use the new /documents/sections, /documents/templates and POST /documents endpoints. See Create a Section, Create a Template, 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.
LeverWherePersistenceUse when
1. Use as-isReference an existing section or template by idn/aThe resource already does what you need
2. Inherit (inheritFromId)POST /documents/sections or POST /documents/templatesPersistent, 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 overridesPOST /documents (Paths 2 & 3)Ephemeral. A drift-proof auto-generated template aggregate is persisted for traceability (30-day retention — see Guided Synthesis); 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.
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.

​
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.

Pattern 1 — Label-based filtering

Save each user’s template / section as a Corti resource and tag it with a label like { "key": "userId", "value": "<uuid>" }. At runtime, LIST /documents/templates?label=userId:<uuid> 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).

Pattern 2 — Your-side persistence

Persist user templates and overrides in your own database. At generation time, parse them into a dynamicTemplate 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.

1. Use a Corti Standard as-is

Reference a curated Corti template by UUID. Lightest, fastest, no side-effects. Ideal for production traffic.

2. Inherit from a Corti Standard

Fork a Corti Standard via inheritFromId. Persistent, versioned, auto-tracks upstream improvements on un-overridden fields.

3. Standards + per-call overrides

Reference a Standard at runtime with templateRef.overrides. End-user-style tweaks (presets or free-prompt) without persisting anything.

4. Author your own

Stable, governed sections + templates owned by your project. Versioned and publishable; full control over prompts and schema.

5. Own + runtime overrides

Pair your stable templates with per-call runtime overrides — last-mile end-user control without per-user resource sprawl.

6. Inherit your own to scale

Keep one canonical section + customer/department-specific inheriting variants. Canonical improvements propagate everywhere.

7. The full stack

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 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:
FieldMerge behavior
instructions.contentPrompt, writingStylePrompt, miscPromptPer-field partial. Any field you omit is inherited from the parent’s published version.
outputSchemaWholesale replacement. Whatever you submit fully replaces the parent schema. Partial schemas are not merged.
title / section headingWholesale 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.
  • 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.

Create a Section

Author sections and create inheriting variants via inheritFromId.

Section Schemas

Schema patterns for the outputSchema choices in these recipes.

Create a Template

Compose sections into templates; create inheriting templates via inheritFromId.

Guided Synthesis

Where runtime overrides happen — Paths 2, 3 and 4 of POST /documents.