Email & document templates module — JetSetGo MCP reference

The emailtemplates module manages JetSetGo's two template systems. Email templates live in a single table where every kind of operator email is distinguished by a flavour — the triple of purpose, context entity, and channel; the same table also holds SMS authoring rows even though no SMS send path exists yet. Document templates are the separate ticket/boarding-pass print layouts that reference uploaded files.

What the operator uses it for

Authoring and maintaining customer-facing communications:

Booking-confirmation emails (optionally rendering the customer-facing reservation hierarchy).
Finalized pick-up notifications and gift-voucher delivery messages.
Marketing emails — plus authoring-only SMS copy.
Ticket and boarding-pass print templates: registering an uploaded file reference, renaming it, or removing it.

Assistants can check whether a template is wired into a live send path before proposing edits, and every content-bearing save is validated against the authoritative flavour registry before anything changes.

Where it sits

Templates are consumed downstream by the send paths: tenant settings selectors decide which template plays each role (confirmation, pick-up, voucher delivery), individual resources can override the template used for their own notifications, marketing campaign flows reference their templates directly, and document templates feed ticket printing. Variable knowledge flows the other way: a centrally served flavour registry — shared with the native template studio — defines which {{variables}} may appear on each surface, and this module validates against it rather than keeping its own copy.

Key concepts

Flavour — a template's identity: purpose (template_type) × context entity (template_context: booking / client / service / gift_voucher) × channel (email / sms). The triple, not context alone, distinguishes rows.
Flavour registry — the served catalogue of allowed variables per surface (main body, ticket loop, SMS body), with token descriptions, examples, and required/conditional flags.
Authority split — marketing templates are re-validated at send time, so authoring errors can hard-block; booking/pick-up/voucher renderers pass unknown tokens through as literal text, so authoring validation warns only.
SMS authoring-only — SMS rows can be created, read, and edited, but nothing sends them; this is deliberate.
Reservation-list fragments — three booking-confirmation-only HTML pieces rendering root products, package components, and add-ons, anchored in the body via {{reservation_list_html}}.
Live-bound template — one referenced by an actual send path (campaign flow, A/B test, selector); edits affect the next real send.
Document template — a print layout referencing an already-uploaded file; distinct lifecycle from email rows.
Drafts are studio-only — unsaved studio work lives in an undiscoverable draft store this module neither reads nor writes.

Tools

Tool	Class	Purpose
`emailtemplates_list`	Read	List non-deleted email templates (summary fields only) with flavour triple and category; filter by purpose, context, channel.
`emailtemplates_get`	Read	Fetch one full email template including HTML body, SMS body, design JSON, and flavour columns.
`emailtemplates_save`	Guarded write	Create or update an email/SMS template with registry-backed variable validation, category derivation, and live-binding warnings.
`emailtemplates_delete`	Guarded write	Soft-delete an email template (sets deleted=true; reversible).
`emailtemplates_documents_list`	Read	List ticket/boarding-pass document templates.
`emailtemplates_documents_get`	Read	Fetch one document template by id.
`emailtemplates_documents_save`	Guarded write	Create a document template (all four fields required) or rename one (only friendly_filename mutable).
`emailtemplates_documents_delete`	Guarded write	Hard-delete a document template permanently.

Rules worth knowing

Creation requirements differ by medium: an EMAIL template requires template_name + subject_template + html_content; an SMS template (channel="sms") requires template_name + body instead.
Save-time validation runs whenever surface content is written and the row resolves to a known flavour. A definitive failure blocks marketing saves outright and merely attaches warnings elsewhere; if the registry endpoint cannot be reached, validation fails open so a save is never bricked — marketing remains protected by its own send-time enforcement.
A save through this module is an immediate commit to the real table. There is no draft staging.
On update, the tool checks live bindings — active marketing flows, A/B tests, tenant settings selectors, and per-resource selectors — and warns when the template is in use. The check is best-effort (degraded fallback covers fewer sources) and never blocks.
Legacy palette category derivation applies only when context is gift_voucher or service and no explicit category was given; booking/client rows are deliberately left untouched, explicit values win, and marketing rows are never rewritten.
Reservation-list fragments belong exclusively to the booking-confirmation flavour: moving a template away from booking clears all three; supplying them on a non-booking write is rejected; omitted values on established templates preserve saved styling; explicitly blank ones resolve to current registry defaults.
Optional columns (flavour fields, reservation fragments, soft-delete tracking) are probed per tenant: untracked columns are omitted from reads and refused — with a clear error — on writes, instead of surfacing cryptic storage errors.
Deletion asymmetry is deliberate: email templates soft-delete and remain recoverable; document templates hard-delete permanently.

Settings — holds the selectors that assign each flavour's default template.
Bookings — booking confirmations render reservation data through these templates.
Tickets — document templates drive ticket/boarding-pass printing.