Understanding Template Methods in Corti's API
Introduction
Corti's API provides three distinct methods for utilizing and customizing document templates, each offering different levels of customization and flexibility. These methods range from using ready-made templates to building highly customized solutions through template section overrides. Understanding these approaches enables developers to choose the most appropriate method based on their specific documentation needs and customization requirements.
Use the links below to jump to your preferred method
Method 1: Corti Default Templates
Method 2: Stitching Pre-built Sections
Method 3: Template Section Overrides
Templates
Templates are utilized as part of a document creation workflow through the Generate Document endpoint. A templateKey value is entered within the body of the call to determine which template will be used to generate the document.
Template keys for Corti's default templates can be retrieved using the List Templates endpoint by parsing the 'key' field within the 'data' object. Accuracy is essential when entering template keys, as they must match the response exactly for successful document generation. Any mismatch between the entered key and existing keys will result in document generation failure.
Learn more in our complete templates documentation.
Template Sections
Sections function as the building blocks of document templates. Each section is an object that defines content output rules, writing style, formatting rules, and language utilizing underlying prompts and logic. All templates contain at least one section, with each section possessing its own unique key.
As shown below in Method 2, templates can be constructed by combining multiple section keys, which are available in the response body from the List Template Sections endpoint. Individual section keys can be obtained by parsing the 'key' field within the 'data' object. The same accuracy requirement applies to section keys as to template keys. Each key must be entered exactly as returned in the response to ensure proper document generation, as any discrepancy will cause the process to fail.
Learn more in our complete sections documentation.
The methods shown below will illustrate how to use and customize Corti's default templates and template sections to allow for flexible document outputs.
Methods for Utilizing and Customizing Corti's Documentation Templates
Method 1: Corti's Default Templates
Ready to use out-of-the-box with no customization
Corti's pre-built templates are accessible via dedicated endpoints documented in the API reference. Users can retrieve a complete list of available templates using the List Templates endpoint, which returns all templates currently offered by Corti. To retrieve the template keys, parse the 'key' field within the 'data' object.
For accessing individual templates, the API provides a Get Template endpoint, as well.
To create a document with the desired template, enter the appropriate template key value to the templateKey field when constructing the generate document call.
Template keys must match the response exactly for successful document generation. Any mismatch between the entered key and existing keys will result in document generation failure.
This method is particularly well-suited for situations requiring basic templates without customization. The templates are immediately usable and require no additional configuration or setup.
Example Call
Example Call
Ensure the correct value is added to the templateKey field shown in the example below.
curl --request POST \
--url https://api.eu.corti.app/v2/interactions/{id}/documents/ \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--header 'Tenant-Name: <tenant-name>' \
--data '
{
"context": [
{
"type": "facts",
"data": [
{
"text": "<string>",
"source": "core",
"group": "Others"
}
]
}
],
"templateKey": "<string>",
"outputLanguage": "<string>",
"name": "<string>",
"disableGuardrails": true,
"documentationMode": "global_sequential"
}
See full documentation for Standard Document Generation here
Method 2: Stitching Pre-Built Template Sections
Flexible Ordering of Sections
The second method allows developers to construct configurable templates by combining individual template sections that are pre-built by Corti in the desired order. This approach provides greater flexibility than using out-of-the-box templates while still leveraging Corti's existing components.
Template sections are accessible through the List Template Sections endpoint, which returns all available pre-built sections from the Corti database. Section keys can be gathered by parsing the 'key' field within the 'data' object of the response.
Since every template consists of an array of sections, users can assemble their own template structure by selecting and ordering these sections according to their needs.
The ordering process involves adding individual section keys to the API call in the desired sequence. The sections will appear in the template in the exact order they are specified within the Generate Document call body. For example, when creating a SOAP note (which traditionally consists of Subjective, Objective, Assessment, and Plan sections), a user could reorder these components by specifying the Plan section key first, followed by the Subjective, Objective, and Assessment section keys.
This method provides access to the building blocks Corti uses to construct its default templates, enabling users to create customized template structures through reordering and recombination.
Example Call
Example Call
curl --request POST \
--url https://api.eu.corti.app/v2/interactions/{id}/documents/ \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--header 'Tenant-Name: <tenant-name>' \
--data '
{
"context": [
{
"type": "facts",
"data": [
{
"text": "<string>",
"source": "core",
"group": "Others"
}
]
}
],
"template": {
"description": "string",
"sections": [
{"key": "sectionkey1"},
{"key": "sectionkey2"},
{"key": "sectionkey3"},
{"key": "sectionkey4"},
]
"outputLanguage": "<string>",
"name": "<string>",
"disableGuardrails": true,
"documentationMode": "routed_parallel"
}
See full documentation for Advanced Document Generation here
Method 3: Template Sections with Overrides
Flexible ordering of sections and output customization
The third method represents a hybrid approach that combines the template section stitching of Method 2 with the ability to apply template section overrides.
This method offers the highest level of flexibility available through the Corti API.
When using the generate document endpoint with this method, users must first stitch together the desired template sections in the desired order. Within those sections, multiple override options become available.
Plain Language Name | Field Name | Field Purpose |
Section Name | nameOverride | to return a different section name (title) |
Writing Style | writingStyleOverride | to prompt how the writing style should be, e.g. telegraphic, laymen, etc |
Formatting Rules | formatRuleOverride | to prompt format, e.g. bullets, subheadings, etc |
Content | contentOverride | controls what input content (facts) get assigned this section, and guides content |
Additional Instructions | additionalInstructionsOverride | to prompt with additional instructions or context |
Overrides do not overwrite the underlying logic or instructions of the template section, but rather provides a one-time instruction to create a different document output. If overrides need to be reused, save the overrides and always pass them within the document generation call.
The response of the List Template Sections call will return the default values of each of the named fields above so developers may see the prompts that will be overridden.
This level of control makes the 'Template Sections with Overrides' method particularly valuable for organizations with specific documentation requirements or those seeking to implement specialized workflows that extend beyond standard template configurations.
Override prompts do not take the underlying template section logic into consideration, meaning your prompt is not additive to the underlying logic. Rather, the newly entered prompt instructs the LLM to ignore the existing logic and to instead use the new prompt to determine the output of the section. If the underlying logic needs to be considered, copy it into the override field, and modify as needed.
Example Call
Example Call
curl --request POST \
--url https://api.eu.corti.app/v2/interactions/{id}/documents/ \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--header 'Tenant-Name: <tenant-name>' \
--data '
{
"context": [
{
"type": "facts",
"data": [
{
"text": "<string>",
"source": "core",
"group": "Others"
}
]
}
],
"template": {
"description": "string",
"sections": [
{
"key": "sectionkey1"
"nameOverride": <string>,
"writingStyleOverride": <string>,
"formatRuleOverride": <string>,
"contentOverride": <string>,
"additionalInstructionsOverride": <string>
},
{
"key": "sectionkey2"
"nameOverride": <string>,
"writingStyleOverride": <string>,
"formatRuleOverride": <string>,
"contentOverride": <string>,
"additionalInstructionsOverride": <string>
},
{
"key": "sectionkey3"
"nameOverride": <string>,
"writingStyleOverride": <string>,
"formatRuleOverride": <string>,
"contentOverride": <string>,
"additionalInstructionsOverride": <string>
},
{
"key": "sectionkey4"
"nameOverride": <string>,
"writingStyleOverride": <string>,
"formatRuleOverride": <string>,
"contentOverride": <string>,
"additionalInstructionsOverride": <string>
},
]
"outputLanguage": "<string>",
"name": "<string>",
"disableGuardrails": true,
"documentationMode": "routed_parallel"
}
See full documentation for Customizing Template Sections here
Conclusion
Corti's API offers three methods for template utilization, each designed to meet different levels of customization needs. Method 1 provides immediate access to pre-built templates for basic use cases. Method 2 enables custom template construction through section reordering. Method 3 delivers maximum flexibility by combining section stitching with parameter overrides. Selecting the appropriate method depends on the specific requirements of the implementation and the degree of customization necessary for the intended use case.