Base de connaissances

Modèles

Un contenu écrit une fois, versionné et envoyé un grand nombre de fois : depuis la fenêtre de rédaction, depuis votre propre code ou par un agent.

Détails

Un modèle appartient à la connexion plutôt qu'à la personne qui l'a écrit, et c'est toute la raison pour laquelle la première version de cette fonctionnalité a été remplacée. Celle-là était indexée sur l'utilisateur : le modèle d'un coéquipier était invisible pour une clé API d'espace de travail, une intégration ne pouvait donc pas envoyer ce que la personne l'ayant configurée voyait, et supprimer le compte de l'auteur emportait les modèles de l'espace de travail avec lui. Les lignes ont été reprises plutôt que supprimées.
Deux façons de rédiger un contenu. Un arbre de blocs bâti sur les composants de @react-email/components (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock, CodeInline), vérifié à mesure qu'il s'écrit : un nœud invalide ou un href non sûr est donc refusé sur l'appel qui l'a écrit, au lieu d'arriver sous la forme d'un e-mail cassé. Ou bien un balisage que vous avez rendu vous-même : si vos modèles sont déjà des composants react-email dans votre propre dépôt, rendez-les là-bas avec @react-email/render et envoyez le HTML, qui est assaini une seule fois au moment où la version est publiée.
Vingt-trois points de départ et un vierge, présentés dans une galerie plutôt que dans un menu, parce que ce sont des choses qu'il faut regarder avant de choisir entre elles : chaque carte montre donc l'e-mail lui-même. Bienvenue et vérification, reçus et factures, expédition et renouvellements, résumés et annonces, répartis sous quatre rubriques ; chacun s'ouvre dans l'éditeur visuel, où chaque élément peut être déplacé, restylé et supprimé. Quel que soit celui que vous choisissez, il arrive à l'état de brouillon : rien n'est envoyable tant que vous ne l'avez pas publié.
La galerie est la seule partie de tout ceci qui n'existe que dans l'application. Un appelant qui atteint les modèles depuis votre propre code ou depuis un agent envoie un contenu (un document de blocs ou votre propre balisage) plutôt que de nommer un point de départ : les vingt-trois sont donc un endroit par où commencer, pas un catalogue à installer.
Les slots nommés et les props nommées sont les deux sortes de trous, écrits {{key}} dans le contenu comme dans l'objet. Un slot est rempli par qui édite le modèle et porte une valeur par défaut : un envoi qui ne nomme rien s'affiche quand même. Une prop est fournie à l'envoi, et une prop marquée required fait refuser l'envoi lorsqu'elle est absente : un 422, et aucun message ne part. Ce refus est tout l'intérêt de la déclarer : l'alternative, c'est un message qui part avec un blanc là où devrait figurer le numéro de commande, ce que rien ne signale et que personne ne peut rattraper.
Une version publiée est figée. Modifier le contenu d'un modèle publié crée un nouveau brouillon plutôt que de réécrire ce qui est en ligne : les envois continuent donc de résoudre ce qu'ils résolvaient hier jusqu'à ce que quelqu'un publie, et un envoi qui épingle un numéro de version n'est même alors pas affecté. Le contenu est compilé à la publication, ce qui fait qu'un modèle qui ne s'affiche pas échoue pour la personne qui le publie plutôt que pour un destinataire.
L'aperçu affiche exactement ce qu'un envoi produirait, sans l'envoyer, et signale ce qui est encore vide au lieu de refuser. Un modèle dont on regarde l'aperçu est en général un modèle en cours d'écriture, et un auteur qui remplit un bloc à la fois ne devrait pas avoir à satisfaire chaque prop pour voir où il en est.
Chaque modèle tient son propre relevé de ce qu'il a envoyé : combien de messages sont partis sur les sept, trente ou quatre-vingt-dix derniers jours, lesquels ont été ouverts et lesquels ont été cliqués, une série jour par jour, et une répartition selon la provenance de chaque envoi : la fenêtre de rédaction, votre code, un agent ou la file d'attente. Chaque taux nomme son propre dénominateur au lieu d'en emprunter un, parce qu'ils sont réellement différents : les ouvertures sont comptées sur les messages qui portaient un pixel, les clics sur les messages qui portaient un lien réécrit, et un message peut porter l'un sans l'autre. Un aperçu n'est jamais enregistré, et un envoi de test est compté à part et exclu de chaque chiffre, parce qu'il n'est jamais parti.
Ce relevé est honnête sur ce qu'il ne peut pas voir, et c'est la raison de faire confiance à la moitié qu'il voit. Un envoi est rapproché de son enregistrement de distribution par l'envoi lui-même, et seul le courrier envoyé depuis votre propre code ou depuis la file d'attente en porte un. Un message envoyé depuis la fenêtre de rédaction, depuis un agent ou par l'assistant n'en porte pas. Un modèle utilisé surtout depuis la fenêtre de rédaction arrive donc avec la plupart de ses envois non rapprochés, et ce nombre non rapproché est affiché comme un chiffre à part plutôt que fondu dans un « personne ne l'a ouvert ».
Quatre surfaces au-dessus d'un seul service, pour que « que veut dire publier » ait une seule réponse plutôt que trois qui s'accordent aujourd'hui. Le bouton Modèles de la fenêtre de rédaction propose les modèles publiés et REMPLACE le message par celui que vous choisissez au lieu de le coller dedans : l'envoi nomme le modèle, la version est épinglée au moment où vous le choisissez, et le contenu est rendu là où il a été rédigé ; une publication survenue entre le choix et le clic ne peut donc pas changer ce qui part, et une mise en page que la fenêtre de rédaction n'aurait pas pu porter survit intacte. Ce que vous remplissez là, ce sont les valeurs, pas le contenu. /templates, ce sont neuf points de terminaison derrière les scopes templates:read et templates:write, enveloppés méthode pour méthode par le SDK. Envoyer un modèle demande une permission d'envoi en plus d'une permission sur les modèles : une clé délivrée à un outil de rédaction peut donc rédiger et publier sans pouvoir écrire à qui que ce soit. Le serveur MCP porte cinq outils : lister, lire, prévisualiser, créer et envoyer. Il n'existe délibérément aucun outil pour mettre à jour, supprimer ou publier un modèle existant. Une modification crée un brouillon vers lequel le prochain envoi ne se résoudrait pas, et une suppression ne peut pas être annulée. Modifier un contenu stocké se fait sur un écran : /workspace/templates porte un canevas de blocs avec une palette et un inspecteur, un aperçu en direct à côté, et Enregistrer et Publier comme deux actes distincts — c'est ce qui fait d'une version publiée quelque chose qu'on peut laisser tranquille pendant qu'on travaille sur la suivante.
200 modèles par connexion, un document de blocs plafonné à 500 blocs, huit niveaux d'imbrication, 20 000 caractères dans une même valeur, 100 slots et 100 props ; un contenu envoyé sous forme de balisage plafonné à un million de caractères, et un objet à 998. Chacune de ces limites est un garde-fou contre un script emballé plutôt qu'une limite de forfait, chacune refuse avec un message qui nomme le nombre sur lequel elle a refusé, et rien dans les modèles n'est réservé à un palier.