Update a template
Authorization
ApiKeyAuth API key from API Keys in the dashboard menu.
In: header
Path Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
curl -X PATCH "https://example.com/api/v1/templates/string" \ -H "Content-Type: application/json" \ -d '{ "document": "#let data = (customer: \\"Acme Ltd\\",)\\n= Invoice for #data.customer" }'Get a template GET
Returns a single template including its `document` and its `fields`: the keys you can pass in the `data` object of `POST /api/v1/renders`. `document` is the template itself: Typst source, or the canvas document as a JSON string. It is here because `PATCH` takes a whole document, so editing is read-change-write. If you only need the field schema, `GET /api/v1/templates/{id}/fields` skips the body. **`?version=N` reads a saved version** and changes nothing. Restoring is how you go back, but it immediately changes what every unpinned Dynamic URL, connected form and render call serves, so it is the wrong way to find out what a version contained. Numbers come from `GET /api/v1/templates/{id}/versions`. Each field carries `primary`: `true` for content (the reason the field exists), `false` for everything else. Canvas fields also carry `tier`, which says where a field belongs in an interface you are building: - `content`: the reason the layer exists (`text`, `src`, `value`). Show these. - `styling`: a colour (`fill`, `borderColor`, `stroke`, a QR's `foreground`). Show these behind a "show more": a brand colour that changes per run is a real thing to want. - `advanced`: everything else that is settable: font family and weight, alignment, corner radius, border width, shadows, outlines, highlights, letter case, word breaking, fit behaviour. Accepted in `data` like any other field, and not worth putting in a form, because these are the template author's decisions and a five-layer design has over a hundred of them. Typst and DOCX fields have no `tier`; every field is content. **Field schema by engine:** - **Typst**: keys extracted from the template source: `{ key, type: "text", example, primary: true }` where `example` is the placeholder value in the source. - **Canvas**: one entry per settable layer property, keyed `layerName.property`: `{ key, label, type, example, primary, tier }`. - **DOCX**: the template's authored field definitions with richer metadata: `{ key, label, type, required, primary: true }` where `type` is one of `text`, `date`, `number`, or `array`. **Canvas templates also return `layers`**: the same properties grouped by the layer they belong to, which is how the template is actually built. Each property carries the full dotted `key` to send in `data`, so you never have to build it yourself. Not every visual attribute is settable. Position, size, rotation, opacity and font size are design-time only: they are changed in the template editor, and are absent from both `fields` and `layers`. Sending them in `data` has no effect. **`archived: true` appears only on an archived template**, alongside `archived_at`. Archived templates are absent from `GET /api/v1/templates` but still render and are still readable by id, so this is the only place a caller holding an id learns the template has been put away. Archiving and unarchiving are dashboard actions. > `available_fields` is a deprecated alias for `fields` and will be removed. Use `fields`.
Move a template to the trash DELETE
Moves the template to the trash, where it stays recoverable for 7 days. Renders, forms and automations that reference it keep resolving until it is purged: deleting a template does not retroactively break the documents made from it. There is no API for the permanent delete. That one is irreversible and stays behind a person clicking it in the dashboard.