Templates / The editor

The template editor

The editor is where you write a template and test it before publishing. It is a split view: your HTML + Handlebars on the left, an inspector on the right.

The two panes

• Left: code. A full code editor for HTML with Handlebars placeholders. HTML and {{…}} expressions are syntax-highlighted, and the editor offers autocomplete and inline diagnostics (below).
• Right: inspector. A set of tabs:
  • Preview renders your current draft as a real PDF (see preview).
  • Sample data is a JSON editor for the test payload your template renders against.
  • Contract shows the variables your template needs as a TypeScript type (the shape of the data you post to the API), with required and optional fields and each variable's shape, plus a clear pass/fail on whether your sample data satisfies them.
  • API shows copy-paste snippets pointed at this template.
  • Issues lists any problems found in the template or the sample data.

Sample data

Sample data is a single JSON object. Its keys are the variables your template can reference: a {{customer}} placeholder reads the customer key, {{#each items}} reads the items array, and so on. It is only test data; it is never sent to your users and is not the same as the data you later post to the API. It is the fixture you design against.

The JSON can be temporarily invalid while you type. Saving formats it and requires it to parse.

Autocomplete and diagnostics

As you type {{, the editor suggests the variables the template already expects plus the block helpers (#each, #if, #unless, #with). Each suggestion shows the inferred kind (scalar, list, or object) and whether it is required.

Inline diagnostics flag two kinds of problem in real time:

• Template parse errors in the HTML pane (for example an unclosed {{#each}}).
• Data mismatches in the sample-data pane: a variable the template needs but the data is missing, or a value of the wrong shape (a list used where a scalar is expected, and so on).

These are the same checks the API runs, so fixing them here means your live calls will not hit invalid_data. See the Handlebars reference for the exact rules.

Saving the draft

Editing changes a local buffer; nothing persists until you save (the Save button, or Cmd/Ctrl + S). Saving overwrites the template's single draft. An "unsaved" indicator shows when your edits differ from the last save, and the browser warns you if you try to leave with unsaved changes.

Preview

The Preview tab renders the saved draft into a real PDF and displays it. It runs through the identical Chromium engine, CSS, and page settings as the production API, so the preview is a faithful proof of the final document, not an approximation.

The preview renders when you save, not on every keystroke, which keeps the heavy render off the typing path. It has no side effects: it does not create a generation, and it does not count against your quota.

Publishing

When the draft is right, publish it. That freezes the current draft as a new immutable version and points the template at it. Your draft stays editable for the next round of changes. Read Versioning & rollback for what publishing does and how to undo it.

If your sample data does not satisfy the template's contract when you publish, the editor warns you first ("publishing now will fail for data like this, because...") and lets you publish anyway. It never silently blocks you: the warning is information, since real calls may send data that does satisfy the contract.