create_case_from_document
Every field the create_case_from_document tool accepts — fill a library document and send it for signing, the same as POST /v3/api/documents/{id}/cases.
Creates a case whose document is one from your library, filled with the values in tags, and — unless it is a draft — sends it. It accepts the same payload as POST /v3/api/documents/{id}/cases (with the document id as an argument instead of in the URL) and runs through the same handler as create_case — recipients, settings, sender and the returned case are identical.
The schema is strict: unknown fields are rejected, inside tags as well, and every problem in a payload comes back at once, each with a field path.
The assistant should call get_document first and build tags from its fields. The tool rejects unknown keys, values for automatic (global, hidden, computed) fields, wrong types, and missing required fields — so a guessed payload fails loudly rather than producing a document with blanks.
Top-level fields
| Field | Type | Notes |
|---|---|---|
id | ObjectId | Required. The document id, from list_documents |
title | string, 1–300 | Required |
tags | object | Values for the document's fields, keyed by path. See Tags |
versionId | ObjectId | Pin a specific version of the document. Default: the current version |
signObligated | boolean | The document must be signed. Default true; false attaches it for reading only |
documentMustBeRead | boolean | Must be opened before signing. Default false |
signatories | int array | Indexes into recipients — which of them sign. Default: all signers |
recipients | array ≤ 100 | Required non-empty when state is open. Same shape as in create_case |
state | open | draft | Default open. draft saves the case with the values still editable in the dashboard |
referenceId | string ≤ 200 | Your own external reference |
folder | string ≤ 200 | Folder name in the dashboard |
senderId | ObjectId | Attribute the case to this company member (wins over senderEmail) |
senderEmail | Attribute by address instead | |
messageTemplateId | ObjectId | Message template for the invitation |
presetId | ObjectId | Preset that fills unset settings (and overrides locked fields) |
settings | object | Same as in create_case — defaults apply even when omitted |
There is no documents array and no document name — the document is the one named by id, and the attached file keeps the library version's own name.
Tags
An object keyed by each field's path from get_document. Nested fields are nested objects, lists are arrays of rows, a template passage is a string or { "text", "values" }:
{
"tags": {
"employee_name": "Andreas Lauridsen",
"start_date": "2026-09-01",
"weekly_hours": 37,
"address": { "city": "Aarhus", "zip": "8000" },
"other_benefits": [{ "name": "Phone", "value": "Paid by employer" }]
}
}| Field type | Send |
|---|---|
string | a string; for date something Date can parse (ISO 8601 is safest); with options, one of the options[].value strings |
number | a JSON number, not a numeric string |
boolean | true/false; a required boolean must be true |
array | rows shaped like item |
conditional (visible set) | only when its rule holds against the other values — otherwise leave it out |
automatic (automaticFields) | nothing — these are filled from the account, the field's default, or other fields |
Only a docx has fields. Sending any tags key for a pdf document is rejected.
Example call
{
"id": "6a394ed08ee8c3669f2c3e17",
"title": "Offer letter — Andreas Lauridsen",
"recipients": [
{ "name": "Andreas Lauridsen", "email": "al@example.com" }
],
"tags": {
"name": "andreas",
"role": "Engineer",
"start_date": "2026-09-01",
"is_senior": true,
"terms": [{ "title": "Pay", "description": "Monthly, in arrears" }]
},
"settings": { "expiresInDays": 14 }
}Result
The tool returns JSON. On success, the same case object as create_case and the REST endpoints — id, state, recipients with their signing links, the rendered document, delivery status and any notices. The .docx is filled and rendered to PDF, so the attached document is a .pdf.
On failure the result is marked as an error and explains itself, with paths relative to the call:
{
"error": "validation-failed",
"details": [
{ "field": "tags.nope", "message": "unknown field" },
{ "field": "tags.company_name", "message": "is a global field and is filled from the account" },
{ "field": "tags.name", "message": "must be one of: inam, andreas" },
{ "field": "tags.employee_name", "message": "is required" }
]
}document-not-found means the document is not the connection's to use (see What you see); a versionId that belongs to another document is a validation-failed on versionId.
A call that does not match the schema at all — a missing title, say — is rejected by the protocol layer as an invalid params error before the tool runs; same information, different envelope.
Asking twice creates two cases. There is no idempotency key. If the assistant reports an error or a timeout, check the dashboard before asking again — see Troubleshooting.