Modèles d'e-mails transactionnels

Yayaw gère les modèles d'e-mails transactionnels depuis /dashboard/content/email-templates. Cette route est un catalogue Yayaw Table pour rechercher, filtrer, créer, supprimer et ouvrir les modèles. Chaque ligne ouvre l'éditeur React Email dédié à /dashboard/content/email-templates/[slug].

Docs liées :

Vue d'ensemble du CMS pour comprendre comment les modèles partagent des variables avec le système de contenu plus large
Modèles de données CMS pour les variables CMS globales
Produits de facturation pour les événements d'achat et d'abonnement

Rôle CMS

Les modèles d'e-mails transactionnels sont des surfaces de communication gérées comme du contenu. Ils partagent les patterns d'édition, de localisation, de variables et de plan de contrôle (control plane) avec le CMS, mais ils ne sont pas rendus par le runtime des pages publiques. Les expéditeurs runtime chargent les modèles actifs, appliquent les variables transactionnelles, résolvent les variables CMS et retombent sur les valeurs par défaut des composants React Email quand aucun modèle n'existe en base.

Utilisez les modèles d'e-mails pour les confirmations d'achat, mises à jour d'abonnement, invitations et autres messages pilotés par événements. Utilisez les pages et sections pour le contenu web public ou réservé aux membres d'organisation.

Modèle de données

Chaque modèle stocke :

slug, name, subject, preview_text, description, category
exports html rendu et text brut utilisés par l'envoi runtime
editor_document, le document JSON TipTap de React Email Editor
default_locale, locales et localized_content pour les variantes traduites inline
variables, le contrat {{variable}} propre au modèle
sample_variables, utilisées par l'aperçu externe et les envois de test
design hérité, conservé uniquement pour que les anciennes lignes Unlayer puissent migrer proprement

Les modèles sont à l'échelle plateforme en v1. Les surcharges propres aux organisations devront être ajoutées plus tard comme couche de lookup explicite, plutôt que surcharger la table globale actuelle.

Le plan de contrôle (control plane) de production expose les opérations de modèles pour les clients MCP de confiance :

yayaw_email_templates_list
yayaw_email_template_get
yayaw_email_template_save
yayaw_email_templates_sync_system

Les écritures exigent control-plane:write ou control-plane:admin, l'autorisation Yayaw email-template:update/manage et un reason.

Localisation

Les modèles d'e-mails suivent le même modèle de localisation inline que les pages CMS. La barre d'outils de l'éditeur permet aux auteurs de changer de locale activée, et chaque locale stocke son propre objet, texte d'aperçu, description, HTML, export texte et document éditeur dans localized_content.

Enregistrer une locale met uniquement cette locale à jour. La locale par défaut miroite aussi les colonnes héritées de premier niveau afin que les lookups runtime existants et les anciennes lignes continuent de fonctionner pendant la migration.

Le panneau IA inclut une bascule de synchronisation de locale activée par défaut. Quand un modèle est enregistré, la locale actuellement ouverte sert de source, et les mêmes changements de texte, structure, style et ordre de blocs sont appliqués aux autres locales activées. Les mises à jour de synchronisation générées par IA écrivent les valeurs localisées subject, previewText, description, html et text ; les valeurs editorDocument des locales cibles sont effacées afin que l'éditeur puisse reconstruire depuis le HTML synchronisé quand cette locale est ouverte.

Le canvas de l'éditeur se concentre uniquement sur le design. La barre d'outils ouvre l'aperçu d'e-mail rendu dans un onglet séparé du navigateur après export du dernier état éditeur et application des variables transactionnelles d'exemple, plus les variables CMS globales.

Variables

Les modèles d'e-mails prennent en charge deux familles de variables :

Les variables de modèle utilisent {{name}} ou des chemins imbriqués comme {{invitation.inviteLink}}.
Les variables CMS utilisent le format de token CMS global, par exemple {site.name} ou {data.global.header-menu.main.brand_label}.

L'éditeur d'e-mail expose les deux familles. Les variables CMS sont résolues via le même catalogue de données globales publiées et de variables de site que celui utilisé par les pages et sections, afin que les auteurs de contenu puissent réutiliser les mêmes valeurs globales dans tout le CMS.

Comportement runtime

Lors de l'envoi d'un e-mail, Yayaw essaie d'abord le modèle actif en base pour le slug configuré et la locale demandée. Si cette locale manque, le rendu retombe sur la locale par défaut du modèle puis sur les colonnes héritées de premier niveau. Si aucun modèle actif n'existe, les e-mails auth continuent d'utiliser le fallback de leur composant React Email.

Les e-mails de facturation sont aussi des modèles système. Ils sont envoyés depuis les handlers de webhooks Stripe et sont volontairement non bloquants : si Resend n'est pas configuré ou si le modèle manque, le webhook journalise le skip et continue de traiter l'achat ou la mise à jour d'abonnement.

Slugs des modèles de facturation intégrés :

billing-purchase-confirmation
billing-subscription-updated
billing-invoice-available

Les modèles de facturation peuvent utiliser des variables imbriquées comme :

{{billing.productName}}
{{billing.amountFormatted}}
{{billing.billingInterval}}
{{billing.billingReason}}
{{billing.optionsSummary}}
{{billing.lineItemsSummary}}
{{billing.discountSummary}}
{{billing.periodStart}} et {{billing.periodEnd}}
{{billing.invoiceId}}, {{billing.invoiceNumber}}, {{billing.invoiceUrl}} et {{billing.invoicePdfUrl}}
{{billing.manageUrl}}
{{billing.accessUrl}}
{{billing.deliverablesSummary}}
{{organization.name}}
{{user.email}}

billing-invoice-available est envoyé depuis les événements Stripe invoice.paid. Le handler est idempotent via billing_webhook_events et résout l'organisation depuis les métadonnées de facture, les métadonnées d'abonnement, puis les lignes locales d'abonnement/client. Le Checkout ponctuel active aussi la création de factures Stripe, afin que les achats lifetime payés puissent générer ce modèle.

Utilisez bun run docs:llm:generate ou l'action dashboard Sync system templates après avoir ajouté des métadonnées de modèles de facturation afin que les variables de l'éditeur et la synchronisation du plan de contrôle MCP restent alignées.

Le HTML stocké est traité comme la représentation runtime rapide. Enregistrez le modèle après édition afin que html, text et editor_document restent synchronisés.

Workflow local

Après modification des contrats de modèles, métadonnées de modèles système, schéma ou docs assistants générées, exécutez :

bun run generate:actions
bun run docs:generate
bun run docs:check-translations
bun run docs:llm:generate
bun run docs:llm:check
bunx tsc --noEmit
bun run check

Pour les variables d'e-mails de facturation, exécutez aussi :

bun test src/lib/server/services/billing/billing-email-notifications.test.ts