# Create document from markdown in PandaDoc tool
Use this tool to create a new document in PandaDoc when there is only text representing the document content.
Document content must be generated according to the guidelines below.
The response includes a 'link' field with a direct URL to open the created document in PandaDoc.
Document creation is asynchronous.
After this tool returns, the document starts in `UPLOADED` status and transitions to `DRAFT` after some time (or to `ERROR` if creation fails).
The document must be in `DRAFT` status before it can be edited or sent.
## Markdown guidelines
You can use standard CommonMark and GitHub-Flavored Markdown (tables, strikethrough, etc), plus the following custom extensions:
### Custom Syntax Extensions
#### 1. Variables
Variables are placeholder values that the document creator fills in PandaDoc before sending to recipients.
Prioritize variables over fields for any value that the sender controls or pre-fills, even if it may be visible to recipients.
**Syntax:** `[VariableName]` or `[Variable.Name]` or `[Multi.Part.Variable]`
- Can include underscores, numbers, and multiple dot-separated parts
**Use variables for values controlled by the document creator:**
- Document metadata: `[Effective.Date]`, `[Agreement.Number]`, `[Contract.Value]`
- Company/sender information: `[Company.Name]`, `[Company.Address]`
- Pre-calculated values: `[Invoice.Total]`, `[Discount.Amount]`
- Recipient information already known: `[Recipient.CompanyName]`, `[Recipient.FirstName]`
**Key principle:** If the sender controls the value, use a variable.
#### 2. Fields
Fields are interactive form elements that recipients fill in or interact with during the signing process.
Recipients see these as input boxes, checkboxes, or signature areas.
**Use fields for values controlled by the recipient:**
- Recipient signatures: `[[signature]]`
- Recipient personal data they must enter: `[[text]]`, `[[email]]`, `[[phone]]`, `[[date]]`
- Recipient choices/consents: `[[checkbox]]`
- Information only the recipient knows or decides
**Key principle:** If the recipient controls the value, use a field.
Fields can be prefilled with default values, but are typically left empty for the recipient to fill.
**Syntax:** `[[field_type attributes]]`
**Field Types:**
- `text` - Text input field
- `email` - Email input field
- `phone` - Phone number input field (**`format` is required** — see below)
- `number` - Number input field
- `date` - Date input field
- `checkbox` - Checkbox field
- `signature` - Digital signature field
- `dropdown` - Dropdown selection field (**`option` is required** — see below)
**Attributes (HTML-style):**
- `required="true"` - Makes field required
- `placeholder="text"` - Placeholder text
- `checked="true"` - Pre-checked (checkbox only)
- `value="timestamp"` - For date fields, use UNIX timestamp with millisecond precision (e.g., value="1718406000000"). For other fields, use plain text (e.g., value="John Doe").
- `format="US"` or `format="international"` - **Required for `phone` fields.** Must be exactly `"US"` or `"international"`. There is no default — omitting it causes a validation error.
- `date_format="yyyy/MM/dd"` - Date format in ICU notation (e.g., `"dd/MM/yyyy"`, `"MM-dd-yyyy"`). Defaults to `"yyyy/MM/dd"` if omitted.
- `option="Text"` - **Required for `dropdown` fields.** Repeatable — add one per option (e.g., `option="Yes" option="No"`). To assign a stable UUID to an option, use `option="uuid:Text"` format.
- `id="Client_Text1"` - Specify an external ID that describes who should fill this field and what it represents (e.g., `id="Client_Signature"`, `id="Landlord_FullName"`, `id="Buyer_Email"`). Use the pattern `<RecipientRole>_<FieldPurpose>` so the field can later be assigned to the correct recipient. Multiple fields MAY share the same ID (they'll be synced — when one is filled, all are filled with the same value), but they MUST have the same type and attributes.
**Examples:**
- `[[text placeholder="Enter name"]]`
- `[[email required="true" placeholder="Email address"]]`
- `[[phone format="US"]]`
- `[[phone format="international"]]`
- `[[number]]`
- `[[date required="true" value="1718406000000"]]`
- `[[date date_format="dd/MM/yyyy"]]`
- `[[checkbox checked="true"]]`
- `[[dropdown option="Yes" option="No"]]`
- `[[dropdown option="Yes" option="No" value="Yes" placeholder="Choose..."]]`
**Important:** Fields with the same ID must have the same type and attributes. For example, you cannot have `[[text id="Field1"]]` and `[[email id="Field1"]]` in the same document as well as `[[text id="Field2" placeholder="Full Legal Name" ]]` and `[[text id="Field2"]]` because they have different attributes.
**Dropdown constraints:**
- At least one `option` attribute is required.
- Option texts must be unique within the dropdown.
- If `value` is set, it must match one of the defined option texts exactly; otherwise a validation error occurs.
#### 3. Standalone Checkboxes
Checkboxes use GFM syntax but can appear anywhere, not just in lists:
- `[ ]` - Unchecked
- `[x]` - Checked
- Can be used inline, standalone, or in task lists
#### 4. Page Breaks
**Syntax:** `---` (three hyphens) creates a page break.
**IMPORTANT:** Page breaks should be rare and intentional. Most documents don't need page breaks.
Only use `---` when content **must** be on separate pages for a specific reason:
- Legal/structural requirement
- Document structure demands it
**Do NOT use `---`:**
- Between sections (use headings: `## Section Title`)
- As visual decoration (use blank lines)
- Simply because there's a section transition
### Limitations (Features NOT Supported)
**Do NOT include:**
- Blockquotes inside lists
- Images inside links inline with text (e.g., `[](link)`)
create-document-from-markdown