Templates
A template is one email design — authored once, rendered many times.
Anatomy
Every template carries:
| Property | Purpose |
|---|---|
| Template key | Stable identifier used by API callers (e.g. order-scheduled-for-delivery). |
| Name | Human-readable label shown in admin tooling. |
| Context key | Declares which data model this template expects (e.g. Order, Event). |
| MJML source | The actual markup — header, body, footer, branding. |
| Status | Draft or Published, set per row. |
| Version | Integer; every version is stored as its own row. |
How it works
- A template is authored in MJML and saved against a context key.
- When something needs to send the email, the system loads the template, substitutes data from the matching model, applies translations, and produces final HTML.
- The HTML is delivered to your email provider.
Pairing with a model
The context key is the contract between a template and the application code
that sends it. A template with context key Order can only be rendered with
order-shaped data; the system rejects mismatched payloads up front rather than
producing a broken email.
This means template authors and backend developers can move independently:
- backend code guarantees the shape of
Order - template authors freely reference any field on
Orderwithout touching code
Constraints
- Template keys are lowercase alphanumeric with hyphens, 2–100 characters.
- The combination of
(templateKey, version)is unique. A template key is shared across all of its versions; each version is its own row. - MJML must compile cleanly — broken markup is rejected on save.
- Every fragment referenced from the template must exist before the template itself can be saved.