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.