Docs

Integrating

Templates

Storing a template, rendering it, versioning, and why the variables are declared.

A template is a stored subject, HTML and text body with declared variables. POST /templates creates one, GET /templates/{id} reads it, and a send references it instead of carrying the body.

Variables are declared, not inferred

A template names the variables it expects. A render missing one is refused rather than silently producing "Hello ," — the empty greeting is the single most common defect in transactional mail and it is entirely preventable at the API boundary.

Always ship a text part

A template with HTML and no text alternative is scored worse by most filters and is unreadable in a client that refuses HTML. The text part is not a formality.

Versions

Editing a template creates a version rather than overwriting one. A message records the version it rendered, so a mail a customer forwards you six weeks later can be reproduced exactly as they received it.

Preview before you send

POST /templates/{id}/render returns the rendered subject, HTML and text for a set of variables without sending anything. Use it in your own tests: a template that stops rendering is a defect you want at build time.

What templates do not do

They do not personalise beyond substitution, and there is no list-building or audience import attached to them. If a feature would make sending to people who did not ask easier, it is not here.