Templates & Folders¶

Reusable workflow templates: create one from an existing document, organize them into folders, and instantiate them into new workflows.

Endpoint summary¶

Method	Path	Summary
GET	`/organization/v1/templates`	List templates (paginated)
GET	`/organization/v1/templates/all`	Lightweight id+name list, for pickers
GET	`/organization/v1/templates/{templateId}`	Get one template
GET	`/organization/v1/templates/{tempId}/use`	Instantiate into a new draft workflow
POST	`/organization/v1/templates`	Create a template
PUT	`/organization/v1/templates`	Update a template
PUT	`/organization/v1/rename/templates`	Rename
PUT	`/organization/v1/templates/move`	Move to a folder
POST	`/organization/v1/templates/{id}/clone`	Clone
DELETE	`/organization/v1/templates`	Delete one or more
GET	`/organization/v1/templates/download/{id}`	Download the source document
GET	`/organization/v1/template-folders`	List folder children
GET	`/organization/v1/template-folders/tree`	Full folder tree
POST	`/organization/v1/template-folders`	Create a folder
PUT	`/organization/v1/rename/template-folders`	Rename a folder
DELETE	`/organization/v1/template-folders`	Delete a folder
GET / PUT	`/organization/v1/template-folders/{id}/access`	Folder role-access control (owner only)
GET	`/workflow/v1/templates/{templateId}/recipients`	Preview a template's recipient/placeholder slots
POST	`/workflow/v1/templates/{templateId}/dispatch`	Instantiate and send immediately
POST	`/workflow/v1/templates/{templateId}/apply`	Instantiate into a draft (no send)

Creating a template¶

POST /organization/v1/templates
Content-Type: application/json

{
  "name": "Standard NDA",
  "description": "Mutual NDA template",
  "workflowId": 887,
  "folderId": 12,
  "recipientLabels": [ { "order": 1, "label": "Client Signer" } ],
  "reminderEnabled": true,
  "reminderIntervalDays": 3
}

Templates are built from an existing (typically draft) workflow — workflowId points at the source, so you always create a template by first preparing a document through Sending & Signing, then saving it as a template instead of (or before) sending it.

recipientLabels is what turns a template's recipient slots into placeholders — the label shown when someone later uses this template and needs to fill in "who is the Client Signer this time." Error: a name collision within the same folder is rejected.

PUT /organization/v1/templates updates in place (same body + overwrite flag); PUT /organization/v1/rename/templates, PUT /organization/v1/templates/move, and POST /organization/v1/templates/{id}/clone handle rename/move/clone. DELETE /organization/v1/templates?ids=1&ids=2 removes them.

Using a template¶

`GET /organization/v1/templates/{tempId}/use`¶

The simplest path — instantiates a template into a brand-new draft workflow and returns its id, for manual review in the editor before sending.

`GET /workflow/v1/templates/{templateId}/recipients`¶

Before dispatching programmatically (or reviewing placeholders in the UI), preview the slots:

[
  { "id": 1, "name": "", "emailAddress": "", "role": "SIGNER", "order": 1, "label": "Client Signer" },
  { "id": 2, "name": "Legal Team", "emailAddress": "legal@example.com", "role": "APPROVER", "order": 2, "label": "" }
]

A non-blank label marks a placeholder that must be filled in before/while dispatching.

`POST /workflow/v1/templates/{templateId}/dispatch`¶

Instantiates the template into a new workflow and sends it immediately — filling in whichever placeholders need real recipients:

[
  { "recipientIndex": 1, "name": "Jane Doe", "emailAddress": "jane@example.com" }
]

Override fields (all optional — anything omitted falls back to the template's stored value):

Field	Validation
`recipientIndex`	1-based, must match an existing template recipient slot
`name`	trimmed, whitespace-collapsed, 3–50 chars, no digits, no symbol characters
`emailAddress`	RFC-like email pattern, ≤255 chars
`recipientColor`, `useDigitalCert`, `recipientPassword`, `recipientOrder`	same as adding a recipient normally — see Sending & Signing → Recipients

Success: 200 OK, { "id": <new workflowId> }. Errors:

Condition	Error
Two overrides resolve to the same email	Duplicate email
A labelled placeholder recipient left unfilled	Required field not filled
Override index out of range, duplicated, or more overrides than template recipients	Bad request
Invalid name/email format	Invalid field value

POST /workflow/v1/templates/{templateId}/apply is identical, but leaves the workflow in DRAFT for manual review instead of sending — this is also the endpoint a partner integration uses. See Partner & Iframe Embed for that angle.

Folders¶

POST /organization/v1/template-folders ({ name, parentFolderId }), GET /template-folders?parentFolderId= (children of a folder), GET /template-folders/tree (whole tree), PUT /rename/template-folders, DELETE /template-folders?ids=.

Folder-level access control (owner only): GET/PUT /template-folders/{id}/access — { roleIds: [...], overrideEnabled: true } restricts which custom roles can see a folder's contents at all, independent of the normal Templates permission a role otherwise has.

Errors: folder doesn't exist, folder already exists, folder not empty (deleting a non-empty folder is rejected), invalid role-access configuration.