SealRoute Template Tags Documentation

This document describes the templating tag system used in SealRoute for creating dynamic documents with form fields and data placeholders.

Overview

SealRoute supports two types of tags:

Key Difference

• [[...]] = Data placeholder → Replaced with values from variables object
• {{...;type=X}} = Form field → Becomes interactive field for signers

Important: Form field tags MUST include type= to be recognized as interactive fields.

Form Field Tags {{...}}

Form field tags create interactive fields that signers can fill out. These tags are processed during PDF generation and converted into actual form fields.

Basic Syntax

{{FieldName;type=fieldtype;role=RoleName;required=true}}

Components

Field Types

Role Assignment

Roles determine which signer is responsible for filling a field. Common roles:

{{BuyerSign;type=signature;role=Buyer}}
{{SellerSign;type=signature;role=Seller}}
{{WitnessSign;type=signature;role=Witness}}

Multiple Signers Example:

BUYER SECTION
{{BuyerSign;type=signature;role=Buyer;required=true}}
Name: {{BuyerName;type=text;role=Buyer}}
Date: {{BuyerDate;type=datenow;role=Buyer}}

SELLER SECTION
{{SellerSign;type=signature;role=Seller;required=true}}
Name: {{SellerName;type=text;role=Seller}}
Date: {{SellerDate;type=datenow;role=Seller}}

Complete Field Examples

# Signature (required)
{{BuyerSign;type=signature;role=Buyer;required=true}}

# Text field
{{CustomerName;type=text;role=Buyer}}

# Auto-date
{{SignedDate;type=datenow;role=Buyer}}

# Initials
{{BuyerInitials;type=initials;role=Buyer}}

# Checkbox
{{AcceptTerms;type=checkbox;role=Buyer;required=true}}

Data Placeholder Tags [[...]]

Data placeholders are replaced with actual values when the document is generated. These are NOT form fields - they display pre-filled data.

Basic Syntax

[[variable_name]]

Common Placeholders

Contract Number: [[contract_number]]
Date: [[contract_date]]
Customer: [[customer_name]]
Company: [[company_name]]
Address: [[customer_address]]
Email: [[customer_email]]
Total: $[[total]]

Nested/Object Placeholders

Access nested data using dot notation:

Product: [[item.name]]
Price: $[[item.unit_price]]
Quantity: [[item.quantity]]

Control Flow Tags

Loops [[for:items]]...[[end]]

Repeat content for each item in a collection. SealRoute supports two types of loops:

1. Paragraph Loops (Regular Text)

For repeating paragraphs or text blocks:

[[for:items]]
Product: [[item.name]]
Description: [[item.description]]
Quantity: [[item.quantity]]
Unit Price: $[[item.unit_price]]
Subtotal: $[[item.subtotal]]

[[end]]

Output (with 2 items):

Product: Enterprise Software License
Description: Annual subscription
Quantity: 1
Unit Price: $15,000.00
Subtotal: $15,000.00

Product: Professional Training
Description: 2-day on-site training
Quantity: 1
Unit Price: $2,500.00
Subtotal: $2,500.00

2. Table Row Loops

For repeating rows in a Word table — the entire table row is duplicated for each item:

[[for:items]] [[end]]

Note: For table loops, place the item accessors in a single row. The [[for:items]] and [[end]] tags can be outside the table or in separate rows.

Loop Syntax Rules

API Data Structure for Loops

{
  "variables": {
    "items": [
      {
        "name": "Product A",
        "description": "First product",
        "quantity": "2",
        "unit_price": "100.00",
        "subtotal": "200.00"
      },
      {
        "name": "Product B",
        "description": "Second product",
        "quantity": "1",
        "unit_price": "150.00",
        "subtotal": "150.00"
      }
    ]
  }
}

Complete Loop Example

Template:

ORDER DETAILS

[[for:items]]
┌─────────────────────────────────────────┐
│ Product: [[item.name]]                  │
│ Description: [[item.description]]       │
│ Quantity: [[item.quantity]]             │
│ Price: $[[item.unit_price]]             │
│ Subtotal: $[[item.subtotal]]            │
└─────────────────────────────────────────┘
[[end]]

TOTAL: $[[total]]

Output:

ORDER DETAILS

┌─────────────────────────────────────────┐
│ Product: Product A                      │
│ Description: First product              │
│ Quantity: 2                             │
│ Price: $100.00                          │
│ Subtotal: $200.00                       │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ Product: Product B                      │
│ Description: Second product             │
│ Quantity: 1                             │
│ Price: $150.00                          │
│ Subtotal: $150.00                       │
└─────────────────────────────────────────┘

TOTAL: $350.00

Empty Loop Handling

If the items array is empty or not provided, the entire loop block is removed from the output.

Conditionals [[if:condition]]...[[end]]

Show content only when condition is true:

[[if:has_discount]]
Discount ([[discount_percent]]%): -$[[discount_amount]]
[[end]]

If-Else

[[if:payment_installment]]
Payment Plan: [[installment_count]] monthly payments of $[[installment_amount]]
[[else]]
Payment Due: Net [[payment_days]] days from contract date
[[end]]

Template Examples

Simple Contract Template

CONTRACT AGREEMENT

Contract Number: [[contract_number]]
Date: [[contract_date]]

---

PARTIES

Seller: [[company_name]]
Address: [[company_address]]

Buyer: [[customer_name]]
Company: [[customer_company]]
Email: [[customer_email]]

---

ORDER DETAILS

[[for:items]]
Product: [[item.name]]
Description: [[item.description]]
Quantity: [[item.quantity]]
Unit Price: $[[item.unit_price]]
Subtotal: $[[item.subtotal]]
[[end]]

---

PRICING

Subtotal: $[[subtotal]]
[[if:has_discount]]
Discount ([[discount_percent]]%): -$[[discount_amount]]
[[end]]
Tax ([[tax_rate]]%): $[[tax_amount]]
TOTAL: $[[total]]

---

SIGNATURES

Buyer Signature: {{BuyerSign;type=signature;role=Buyer;required=true}}
Buyer Name: {{BuyerName;type=text;role=Buyer}}
Date: {{BuyerDate;type=datenow;role=Buyer}}

Seller Signature: {{SellerSign;type=signature;role=Seller;required=true}}
Seller Name: {{SellerName;type=text;role=Seller}}
Date: {{SellerDate;type=datenow;role=Seller}}

NDA Template Example

NON-DISCLOSURE AGREEMENT

This Agreement is entered into as of [[effective_date]]

BETWEEN:
[[disclosing_party_name]] ("Disclosing Party")
AND:
[[receiving_party_name]] ("Receiving Party")

---

CONFIDENTIAL INFORMATION

The Receiving Party agrees to:
{{AcceptTerms;type=checkbox;role=Receiver;required=true}} Keep all information confidential
{{AcceptDuration;type=checkbox;role=Receiver;required=true}} Maintain confidentiality for [[duration_years]] years

---

SIGNATURES

Disclosing Party:
{{DiscloserSign;type=signature;role=Discloser;required=true}}
Name: {{DiscloserName;type=text;role=Discloser}}
Date: {{DiscloserDate;type=datenow;role=Discloser}}

Receiving Party:
{{ReceiverSign;type=signature;role=Receiver;required=true}}
Name: {{ReceiverName;type=text;role=Receiver}}
Date: {{ReceiverDate;type=datenow;role=Receiver}}

Best Practices

Field Naming

1. Use descriptive names: BuyerSignature instead of sig1
2. Include role in name: BuyerName, SellerName for clarity
3. Be consistent: Use same naming pattern throughout
4. Avoid spaces: Use camelCase or underscores

Role Assignment

1. Define clear roles: Buyer, Seller, Witness, Notary
2. Match API submitters: Role names should match submitter roles in API calls
3. One role per signer: Each signer should have a distinct role

Layout Tips

1. Position tags where fields should appear: Tags are replaced with form fields at their exact location
2. Leave enough space for signatures: Signature fields need vertical space
3. Align related fields: Group fields by signer for better UX

Common Patterns

Two-Party Signature Block:

BUYER                                    SELLER
─────────────────────────                ─────────────────────────

{{BuyerSign;type=signature;role=Buyer}}  {{SellerSign;type=signature;role=Seller}}

Name: {{BuyerName;type=text;role=Buyer}} Name: {{SellerName;type=text;role=Seller}}

Date: {{BuyerDate;type=datenow;role=Buyer}} Date: {{SellerDate;type=datenow;role=Seller}}

Required Field Indicator:

* Required fields

Signature*: {{Sign;type=signature;role=Signer;required=true}}
Name*: {{Name;type=text;role=Signer;required=true}}
Phone: {{Phone;type=phone;role=Signer}}

Auto-Date (datenow) Behavior

The datenow field type creates a readonly date field that is automatically filled with the current date when the signer completes the form.

How It Works

1. Place {{SignDate;type=datenow;role=Buyer}} in your DOCX template.
2. The signer cannot edit this field — it is filled automatically on completion.
3. The date is captured at completion time in the account’s timezone and stamped onto the final PDF.

Date Format

By default, dates use DD/MM/YYYY (or MM/DD/YYYY for US locales). Override with format:

{{SignDate;type=datenow;role=Buyer;format=DD/MM/YYYY}}
{{SignDate;type=datenow;role=Buyer;format=MMMM DD, YYYY}}

Important Notes

• datenow fields are not interactive — signers cannot change the date
• The date is set at completion time, not at document creation time
• If you need signers to pick a date, use type=date instead

DOCX Formatting Inheritance

When you use a DOCX template, SealRoute carries the visual formatting of your Word document over to the rendered form fields. You can style your template in Word and the signed PDF will match — no need to specify alignment, font, or font size in every tag.

Automatic Alignment

If a field tag is placed in a centered or right-aligned paragraph in Word, the rendered field follows the same alignment:

                    {{SignDate;type=datenow;role=Buyer}}        ← centered in Word
                    {{BuyerSign;type=signature;role=Buyer}}     ← centered in Word
                    [[Nama_Anggota]]                            ← centered in Word

The field is positioned at the correct spot on the page and its value text is aligned the same way.

Automatic Font Family

The font family used in Word is mapped to a PDF-friendly font:

Other fonts fall back to a universal default.

Automatic Font Size

The font size at the tag’s location in your Word document is used for the rendered value. If your document uses 12pt throughout, all field values render at 12pt.

The size is resolved in this order (first match wins):

1. Explicit font_size=N on the tag (e.g., {{Date;type=date;font_size=14}})
2. The font size of the text surrounding the tag in Word
3. The paragraph’s default font size in Word
4. The document’s default font size (set in Word’s style defaults)
5. System default (~11pt)

Explicit Overrides

Tag attributes always override the DOCX formatting:

{{SignDate;type=datenow;role=Buyer;align=left;font=Courier;font_size=10}}

This forces left alignment, Courier, and 10pt regardless of how the paragraph is styled in Word.

Signature Alignment

By default, drawn signatures are aligned to the left within their field area. You can control this with the align attribute:

{{BuyerSign;type=signature;role=Buyer;align=left}}     ← default
{{BuyerSign;type=signature;role=Buyer;align=center}}   ← centered
{{BuyerSign;type=signature;role=Buyer;align=right}}    ← right-aligned

This affects both the signing UI (where the signature image is displayed) and the flattened PDF output.

Field Size (width / height)

By default, SealRoute auto-sizes each field based on the tag’s position in your Word document:

If you want a taller signature area (or a larger stamp / image / text box), use height= and/or width= on the tag. Values are integer pixels relative to the rendered page image (US Letter is rendered at 1400 × 1812 px internally).

Examples

# Auto-sized (default)
{{BuyerSign;type=signature;role=Buyer}}

# Taller signature box (≈ 11% of page height)
{{BuyerSign;type=signature;role=Buyer;height=200}}

# Explicit width AND height (wider + taller drawn signature)
{{BuyerSign;type=signature;role=Buyer;width=500;height=220}}

# Larger initials box
{{BuyerInit;type=initials;role=Buyer;height=120}}

# Square stamp
{{CompanyStamp;type=stamp;role=Seller;width=240;height=240}}

# Bigger uploaded image field
{{Photo;type=image;role=Buyer;width=400;height=300}}

Rule of thumb on A4 / Letter

Tip: width / height override the auto-size completely. If you only set one (e.g. height=200), the other dimension is still auto-derived from the tag’s position in Word.

API Integration

Variable Scoping ([[...]] vs submitters[].values)

There are two ways to pass data, and they serve different purposes:

[[...]] tags are replaced with content from the variables object. They become static text in the document.

{{...;type=X}} tags become interactive form fields. Pre-fill them with submitters[].values (keyed by field name or UUID).

Role-Scoped Variables

Variables for [[...]] tags can be provided at the top level or nested under each submitter. All are merged into a single map before substitution:

{
  "variables": {
    "contract_number": "C-001",
    "contract_date": "April 15, 2026"
  },
  "submitters": [
    {
      "role": "anggota",
      "email": "member@example.com",
      "variables": {
        "Nama_Anggota": "Muhammad",
        "NRP_Anggota": "1234567890"
      }
    },
    {
      "role": "Buyer",
      "email": "buyer@example.com"
    }
  ]
}

In this example:

• [[contract_number]] and [[contract_date]] come from top-level variables
• [[Nama_Anggota]] and [[NRP_Anggota]] come from the anggota submitter’s variables
• All are merged before substitution (later submitters override duplicate keys)

Submitter Roles

When submitting documents via API, the submitters’ roles must match the roles defined in the template:

{
  "template_id": 123,
  "submitters": [
    {
      "role": "Buyer",
      "email": "buyer@example.com",
      "name": "John Doe"
    },
    {
      "role": "Seller", 
      "email": "seller@example.com",
      "name": "Jane Smith"
    }
  ]
}

Troubleshooting

Tags Not Being Detected

1. Check syntax: Ensure double braces {{ and }}
2. No spaces in tag: {{FieldName}} not {{ FieldName }}
3. Valid field type: Use supported types listed above
4. Check tag format: Use semicolons to separate options: {{Name;type=text;role=Buyer}}

Tags Still Visible in PDF

1. Verify tag format: Tags must be {{name;type=X}} format
2. Check encoding: Ensure the DOCX uses standard UTF-8 encoding
3. Avoid special characters: Don’t use Unicode curly braces — use standard { and }

Field Position Issues

1. Tags may be hyphenated: Word processors can split tags across lines — keep each tag on a single line
2. Use standard fonts: Use Times New Roman, Arial, or Courier New for best results
3. Keep tags on single line: Avoid line breaks within a tag
4. Centered tags: Tags in centered paragraphs are automatically centered on the page
5. Font mismatch: If the rendered date/text looks different from the document font, add font=Times to the tag or ensure the DOCX paragraph uses a recognized font family
6. Font size mismatch: If the rendered text appears too small or too large, add font_size=12 (or whichever point size matches your document) to the tag

Reference

All Supported Field Types

Tag Options Reference

API Submitter Parameters

When creating submissions via API, these parameters are available for each submitter:

Basic Parameters

Communication Parameters

Two-Factor Authentication (2FA)

Phone 2FA Setup

When require_phone_2fa: true:

1. The submitter must have a valid phone number
2. SealRoute sends an OTP code via:
   • Phone OTP Webhook (if configured) - You send SMS via your provider
   • Built-in SMS (if no webhook configured and SMS is enabled)
3. Submitter enters the 6-digit code to access the form
4. OTP codes are valid for 10 minutes

Email 2FA Setup

When require_email_2fa: true:

1. The submitter must have a valid email address
2. SealRoute sends an OTP code via email automatically
3. Submitter enters the 6-digit code to access the form
4. OTP codes are valid for 5 minutes

Note: Email 2FA does not have a webhook option - emails are always sent by SealRoute. Only Phone 2FA supports custom webhook delivery.

Example with 2FA

{
  "template_id": 123,
  "submitters": [
    {
      "role": "Signer",
      "email": "signer@example.com",
      "phone": "+628123456789",
      "require_phone_2fa": true
    }
  ]
}

Field Configuration

Metadata

Workflow & Signing Order

SealRoute supports two levels of signing order control:

Submission-Level Order (Top-Level Parameter)

Values:

• "preserved" - Sequential signing. Second party receives signature request only after the first party signs.
• "random" - Parallel signing. All parties receive signature requests immediately and can sign in any order.

Submitter-Level Order (Per-Submitter Parameter)

Order Groups: Use the same order number for multiple submitters to create parallel signing within a sequential workflow.

Signing Order Examples

Example 1: Sequential Signing (Default)

{
  "template_id": 123,
  "order": "preserved",
  "submitters": [
    { "role": "Buyer", "email": "buyer@example.com" },
    { "role": "Seller", "email": "seller@example.com" }
  ]
}

• Buyer signs first → Seller receives request after Buyer completes

Example 2: Parallel Signing

{
  "template_id": 123,
  "order": "random",
  "submitters": [
    { "role": "Buyer", "email": "buyer@example.com" },
    { "role": "Seller", "email": "seller@example.com" }
  ]
}

• Both Buyer and Seller receive requests immediately, can sign in any order

Example 3: Custom Order with Groups

{
  "template_id": 123,
  "order": "preserved",
  "submitters": [
    { "role": "Witness 1", "email": "witness1@example.com", "order": 0 },
    { "role": "Witness 2", "email": "witness2@example.com", "order": 0 },
    { "role": "Manager", "email": "manager@example.com", "order": 1 },
    { "role": "Director", "email": "director@example.com", "order": 2 }
  ]
}

• Order 0: Witness 1 and Witness 2 sign in parallel (same order group)
• Order 1: Manager signs after both witnesses complete
• Order 2: Director signs last

Example 4: Reverse Order

{
  "template_id": 123,
  "order": "preserved",
  "submitters": [
    { "role": "Employee", "email": "employee@example.com", "order": 1 },
    { "role": "HR Manager", "email": "hr@example.com", "order": 0 }
  ]
}

• HR Manager signs first (order: 0), then Employee (order: 1)

Consent Settings

Consent allows you to require signers to accept terms and conditions before signing documents.

How Consent Works

When enabled, submitters see a checkbox with your consent text and a link to your terms document. They must check the box before they can proceed with signing.

Configuration Levels

1. Account-Level Defaults (Settings UI)

Go to Settings → Consent to configure default consent for all templates:

2. Template-Level Override (Template Settings UI)

In the template editor, go to Settings → Consent to override account defaults:

Template Preferences for Consent

Consent is controlled via template preferences:

API Parameters for Consent

Consent can be configured at top-level (all submitters) or per-submitter (per role):

Priority Order

Consent settings are resolved in this priority:

1. Per-submitter API parameters (highest priority)
2. Top-level submission API parameters
3. Template preferences (set via Template Editor UI)
4. Account defaults (set via Settings → Consent)

API Example: Same Consent for All Submitters (Top-Level)

{
  "template_id": 123,
  "consent_enabled": true,
  "consent_document_url": "https://example.com/terms",
  "consent_document_text": "I agree to the Terms of Service",
  "submitters": [
    { "role": "Buyer", "email": "buyer@example.com" },
    { "role": "Seller", "email": "seller@example.com" }
  ]
}

Both Buyer and Seller see the same consent.

API Example: Different Consent Per Role

{
  "template_id": 123,
  "submitters": [
    {
      "role": "Buyer",
      "email": "buyer@example.com",
      "consent_enabled": true,
      "consent_document_url": "https://example.com/buyer-terms",
      "consent_document_text": "I agree to the Buyer Terms of Service"
    },
    {
      "role": "Seller",
      "email": "seller@example.com",
      "consent_enabled": true,
      "consent_document_url": "https://example.com/seller-terms",
      "consent_document_text": "I agree to the Seller Agreement"
    }
  ]
}

Each role sees their own consent document.

API Example: Consent for One Role Only

{
  "template_id": 123,
  "submitters": [
    {
      "role": "Buyer",
      "email": "buyer@example.com",
      "consent_enabled": true,
      "consent_document_url": "https://example.com/terms",
      "consent_document_text": "I agree to the Terms"
    },
    {
      "role": "Seller",
      "email": "seller@example.com",
      "consent_enabled": false
    }
  ]
}

Only Buyer sees consent; Seller signs without consent.

API Example: DOCX Submission with Per-Role Consent

{
  "name": "Contract with Terms",
  "documents": [{"name": "contract.docx", "file": "BASE64_ENCODED_DOCX"}],
  "submitters": [
    {
      "role": "Buyer",
      "email": "buyer@example.com",
      "consent_enabled": true,
      "consent_document_url": "https://example.com/buyer-terms.pdf"
    },
    {
      "role": "Seller",
      "email": "seller@example.com",
      "consent_enabled": false
    }
  ]
}

Fallback Behavior

If consent_enabled: true but no URL/text is provided:

• consent_document_url falls back to: submission setting → template setting → account default
• consent_document_text falls back to: submission setting → template setting → account default (or “I have read and agree to the terms and conditions”)

Example Consent Flow

┌─────────────────────────────────────────────┐
│         Document Signing Form               │
├─────────────────────────────────────────────┤
│                                             │
│  [Document Preview]                         │
│                                             │
│  ☐ I have read and agree to the            │
│    terms and conditions                     │
│    (Click to view terms)                    │
│                                             │
│  [Sign Document] ← disabled until checked   │
│                                             │
└─────────────────────────────────────────────┘

Audit Trail

When consent is enabled, the audit trail records:

• Timestamp when the submitter agreed to consent
• The consent text that was displayed
• The consent document URL that was linked

Custom Branding

You can customize the logo and company name displayed in the signing form, emails, and audit trail PDF. No DOCX tag is needed — branding is set via API parameters or the Settings UI.

API Parameters

API Example

{
  "template_id": 123,
  "logo_url": "https://example.com/your-logo.png",
  "company_name": "Your Company",
  "submitters": [
    { "role": "Signer", "email": "signer@example.com" }
  ]
}

Settings UI

Go to Settings → Personalization → Company Logo to set:

• Logo URL: URL to your logo image
• Company Name: Your brand name

Where Branding Appears

Important Notes

• Branding is set at the account level — once set, it applies to all submissions
• The API logo_url and company_name parameters update account settings (they persist)
• If no custom branding is set, the default SealRoute logo and name are used
• The logo is NOT embedded in the signed document PDF — it only appears in the UI and audit trail