Modèles d''e-mail
En préversionDes modèles avec de la logique, rendus au moment de l''envoi.
Stockez un objet et un corps une seule fois, publiez-le en tant que version immuable, puis envoyez-le par slug. Les conditions, boucles et filtres Liquid s'exécutent au moment de la génération du message, de sorte que la logique de personnalisation réside dans le template plutôt qu'éparpillée dans votre code. Créez-le dans le builder du tableau de bord, depuis le bird CLI, ou laissez un agent le faire via MCP.
import { BirdClient } from "@messagebird/sdk";
import { render } from "@react-email/render";
import { WelcomeEmail } from "./emails/welcome";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const { data, error } = await bird.email.send({
from: "Bird <hello@bird.com>",
to: ["ada@example.com"],
subject: "Your invite is ready",
html: await render(<WelcomeEmail name="Ada" />),
}).safe();
if (error) throw error;
console.log(data.id);
// → "em_2bX91Yk8h..."
You can sign in any time at bird.com/login.
Your test API key is on your dashboard, ready to send.
Stockez un modèle. Personnalisez à l''envoi.
Le markup est déjà dans Bird.
Les templates font partie de l<hub>API Email de Bird</hub>. Stockez la mise en page et sa logique une seule fois ; chaque envoi désigne le template par slug ou id et transmet les valeurs dont ses tokens ont besoin. Le message final est rendu de notre côté, de sorte que le même template convient à un reçu unique, un lot de cent ou une diffusion à toute une audience.
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
// No subject and no html: the template's published version supplies both.
const { data, error } = await bird.email
.send({
from: "orders@acme.com",
to: ["delivered@messagebird.dev"],
category: "transactional",
template: {
slug: "order-confirmation",
parameters: {
first_name: "Ada",
order: { number: "A-1043", total: "$42.00" },
},
},
})
.safe();
Plus qu''un rechercher-remplacer.
Liquid, résolu côté Bird au moment de la génération du message.
- 01
Conditions.
Un bloc Liquid if ne s'affiche que lorsque sa valeur s'applique, comme une note réservée aux membres ou une bannière de livraison gratuite, de sorte qu'un seul template couvre les deux cas.
- 02
Boucles.
Une boucle for répète une ligne pour chaque élément d'un tableau, de sorte qu'un seul template de confirmation de commande liste chaque article réellement acheté par le client. Une limite à connaître d'emblée : une diffusion ne porte qu'une seule valeur par propriété de contact et n'a rien à itérer, donc un template avec des boucles s'envoie via l'API messages plutôt que par diffusion.
- 03
Filtres.
Passez une valeur à travers un filtre Liquid avant son rendu. Le filtre default intercepte un prénom manquant avant qu'il ne parte sous forme de salutation vide.
- 04
Données imbriquées.
Les tokens avec notation pointée accèdent aux objets structurés, vous pouvez donc transmettre un objet commande entier et adresser son numéro et son total depuis le markup au lieu de l'aplatir au préalable.
- 05
Rien à déclarer.
La liste des tokens est extraite de votre markup, combinée à travers toutes les langues, il n'y a donc pas de schéma de variables séparé à maintenir en phase avec le corps. Les valeurs peuvent être n'importe quel JSON : chaînes, nombres, booléens, tableaux, objets.
Créez-les comme vous travaillez déjà.
Trois points d'entrée, tous menant au même template. Le builder du tableau de bord est l'option visuelle. Le bird CLI pilote tout le cycle de vie depuis un script ou une étape de déploiement, et un agent accède aux mêmes opérations via MCP. Vous avez déjà des composants React Email ? Rendez-les en HTML et stockez le résultat, en laissant les tokens de Bird sous forme de texte littéral dans le JSX pour qu'ils survivent au rendu au lieu d'être figés en valeur lors de l'exécution de React.
# Render React Email to HTML, then publish it as a template version.
node scripts/render-receipt.mjs > receipt.json
bird email templates create receipt --category transactional --source html
bird email templates versions languages set "$TEMPLATE" "$DRAFT" en \
--body-file receipt.json --yes
# --validate-only reports every problem across every language, freezing nothing.
bird email templates versions submit "$TEMPLATE" "$DRAFT" --validate-only --yes
bird email templates versions submit "$TEMPLATE" "$DRAFT" --yes
Versionnés, comme le reste de votre code.
Les modifications se font sur un brouillon et ne touchent jamais ce qui est en production, car un envoi résout toujours la version publiée en cours et les brouillons ne sont jamais envoyés. La publication fige une version immuable et numérotée et la met en production ; si un changement tourne mal, revenez à une version antérieure. Les sauvegardes portent la révision que vous avez lue en dernier, de sorte que si un collègue a modifié cette langue entre-temps, la sauvegarde est refusée comme conflit au lieu d'écraser son travail. Les statistiques de livraison et d'engagement sont ventilées par template, pour que vous puissiez voir lequel fonctionne réellement.
Un template, jusqu'à 25 langues.
Un template porte du contenu dans jusqu'à 25 langues, chacune avec son propre objet et corps, indexée par un tag BCP-47 comme en ou pt-BR. Un envoi nomme la langue souhaitée, ou l'omet et obtient la langue par défaut du template. Quand un envoi demande une langue que le template ne possède pas, on_missing_language décide du comportement : fallback sert la correspondance la plus proche, de sorte qu'une requête pour pt-BR reçoit un pt disponible, et fail rejette l'envoi purement et simplement, pour les contenus où la mauvaise langue est pire que pas d'envoi du tout.
Prévisualisez exactement ce qui sera envoyé.
Remplissez un template avec des valeurs d'exemple et obtenez en retour l'objet ainsi que les corps HTML et texte qu'un envoi livrerait. L'aperçu rend le brouillon, ce qui vous permet de vérifier une modification avant sa mise en production, ou une version publiée quand vous voulez voir ce qui part actuellement. Rien n'est envoyé. Il exécute aussi les mêmes vérifications de personnalisation que la publication, de sorte qu'une construction qui serait rejetée apparaît ici en premier.
Vers où vont les modèles.
Le builder visuel et une bibliothèque de démarrage de quarante templates intégrés sont déjà disponibles, vous pouvez donc en copier un dans votre workspace et le modifier à partir de là. Prochaines étapes : décrivez un template dans un prompt et obtenez un brouillon à affiner, une interface de composition plus resserrée pour les agents, et les kits de marque, qui contiendront vos couleurs, votre typographie et votre ton au niveau du workspace pour styliser un template à partir de ceux-ci. Chacune de ces fonctionnalités étend le même modèle versionné, donc ce que vous intégrez aujourd'hui est ce sur quoi elles s'appuient.
Allez plus loin dans la documentation.
Le guide des templates couvre les brouillons, les versions publiées, le contenu par langue et les règles Liquid. Le guide d'envoi décrit le contrat côté envoi, et événements e-mail et webhooks vous permet de récupérer les ouvertures et les clics.
Le reste de la plateforme Email
Une seule API, un seul jeu de clés. Découvrez les autres capacités.
Les templates sont livrés avec toute la plateforme autour d'eux.
Stockez, versionnez et personnalisez vos modèles sur la même API Email qui gère l''envoi, la délivrabilité, la suppression et l''analyse. Un seul jeu de clés.