Template Tags

NextSign fills .docx templates with data when a document is produced. Anywhere you write a tag in the Word file, the rendered document gets a value instead.

This agreement is made between {company_name} and {kunde_navn}
on {today}.

Tags are what the tags field of Create a Case from a Document and Forms Submit fills. This page documents the syntax you write in the Word file; the endpoint pages document how to send the values.

Value tags

A plain tag inserts a value:

{kunde_navn}

Nested values use a dot:

{kunde.adresse}, {kunde.by}

Values submitted through the API are inserted as you send them. Fields filled through a form or the dashboard are formatted according to the field type set in the tag editor — number fields get . as thousands separator, date fields render as DD/MM/YYYY unless the field defines its own format.

Conditional sections

Wrap a block in {#tag} … {/tag} to include it only when the value is true:

{#har_bilag}
Appendix A is attached to this agreement.
{/har_bilag}

{^tag} … {/tag} is the inverse — included only when the value is false or missing:

{^har_bilag}
No appendices are attached.
{/har_bilag}

A {#tag} … {/tag} block with no tags inside it is read as a condition like this, and the tag becomes a yes/no field. The same block with tags inside it is read as a list instead.

Lists

A list value repeats the block between {#tag} and {/tag} once per item:

{#ydelser}
{navn} — {pris} kr.
{/ydelser}

To repeat a table row, put {#ydelser} in the first cell of the row and {/ydelser} in the last cell. The row itself is repeated, not the text inside it.

A loop like this becomes a list field: rows the sender adds one by one in the dashboard, and an array of row objects through the API — see Tags on the create-case endpoint. The tags inside the block ({navn}, {pris}) are the columns of each row.

Empty-state companions: _has_items and _filled

Every tag automatically gets a boolean companion tag describing whether it has content:

Use them to gate constant text on whether content exists. A heading above a list should render once — not once per row, and not at all when the list is empty:

{#ydelser_has_items}The following services are included:{/ydelser_has_items}
{#ydelser}{navn} — {pris} kr.{/ydelser}
{^ydelser_has_items}No additional services are included.{/ydelser_has_items}

The same works for optional single values — a table row wrapped in {#depositum_filled} … {/depositum_filled} disappears entirely when no deposit was agreed:

{#depositum_filled}Deposit: {depositum} kr.{/depositum_filled}

Rules:

• Companions are computed at render time and are never fields — they don't appear in the tag editor, and the v3 endpoints reject them as unknown fields.
• A companion only exists when the document actually contains the base tag. A {#foo_has_items} section with no {foo} anywhere is treated as an ordinary conditional section with its own yes/no field.
• A real tag you define with that exact name always wins — the computed value never overwrites it.
• They work inside list rows too: within {#ydelser} … {/ydelser}, {#kommentar_filled} checks that row's own kommentar.

Dropdown option tags

A dropdown field's answer also produces a boolean tag per option, so a document can check-mark the chosen option:

Hovedkort {#karttype_hovedkort}✓{/karttype_hovedkort}   Bikort {#karttype_bikort}✓{/karttype_bikort}

When the dropdown karttype is answered with "Hovedkort", {karttype_hovedkort} is true; every other option's tag stays false. The key is {tag}_{option} with the option value slugged: lowercase, spaces become _, and everything except a–z, 0–9, _ and æøå is dropped. Options containing æ/ø/å answer to an ASCII spelling as well — "Pædagog" on the dropdown stilling matches both {stilling_pædagog} and {stilling_paedagog}.

These are derived from the dropdown's answer at render time — the dropdown itself is the only field you fill or send, and a {#karttype_hovedkort} section in the document counts as covered by the karttype dropdown.

Recipient tags

When a recipient carries a naming slug (the recipient-naming field in the form builder, e.g. medarbejder), that recipient's contact details are available as tags:

{medarbejder_name}   {medarbejder_email}   {medarbejder_phone}

The sender never has to fill a separate field with data they already typed in the recipient step. The suffixes are always English (_name, _email, _phone), and a slug containing æ/ø/å also answers to its ASCII spelling ({sælger_name} and {saelger_name}).

A value supplied explicitly for such a tag always wins — the derived value only fills a tag that is missing or empty.

Global fields

These are filled on every render — you never send values for them, they never appear as fields in the tag editor, and the v3 endpoints reject an attempt to set one ("is a global field and is filled from the account"). Times are in Europe/Copenhagen.

The registry is fixed and identical for every account — that is what makes a shared or partner template portable: {company_name} always means the sending company's name, on every account the template lands in.

Date and time

The sending company

Values come from the company profile. Each can be overridden under Dashboard → Config when the contract wording should differ from the profile (a formal legal name, say).

The sender

The person sending the case. Never overridable — the value follows whoever is acting.

Custom global fields

An account can define its own key/value pairs under Dashboard → Config — e.g. {forhandler_navn} — filled on every render just like the system fields. Keys are lowercase snake_case. This is what lets a partner ship one standard document that each customer fills with their own fixed details once, instead of on every case.

Company logo

{@company_logo} inserts the logo of the company the document is produced for — the one uploaded under Dashboard → Company → Details. The same template therefore carries each company's own logo, which is what makes it usable for shared standard documents such as partner agreements.

{@company_logo_w200_center}

PARTNER AGREEMENT

Note the @, which marks an image tag. Size and alignment are part of the tag name:

Suffixes combine in any order: {@company_logo_h60_right}, {@company_logo_40x20mm_center}. The aspect ratio is always preserved — a width and a height together define a box the logo is fitted inside, never stretched to.

The tag works in the body, in table cells, and in headers and footers. When the company has no logo uploaded, the signature logo is used if one is configured; otherwise the paragraph is simply left empty. Logos uploaded in a format Word cannot embed (SVG, WebP) are converted automatically.

Where to see a template's tags

• Dashboard — open the document and use its tag editor, or the API guide panel, which generates a pre-filled sample request.
• API — Forms Tags returns the tags a form expects.

Global fields, the _has_items/_filled companions, dropdown option tags, recipient tags and {@company_logo} are deliberately excluded from both — they are filled for you, so they are never fields you need to send.