Modèles d''e-mail

En préversion

Des modèles avec de la logique, rendus au moment de l''envoi.

Stockez un modèle d''e-mail dans Bird et référencez-le par son id. Conditions, boucles et valeurs par défaut sont rendues par destinataire au moment de l''envoi, pour que la logique de personnalisation reste dans le modèle au lieu d''être dispersée dans votre code. Créez-le en HTML avec des variables déclarées, ou rendez vos composants React Email.

welcome.tsx
200 · 1.2s
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..."

Stockez un modèle. Personnalisez à l''envoi.

N''envoyez que les valeurs qui changent pour chaque destinataire.

Les modèles font partie de l'API Email de Bird. Stockez la mise en page et sa logique une seule fois ; à chaque envoi, vous référencez le modèle et transmettez un ensemble plat de valeurs propres à chaque destinataire. Bird rend le message final de son côté, pour que le même modèle pilote un e-mail ou un million.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import { BirdClient } from "@messagebird/sdk";

const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });

// Store a template once. Conditionals and loops render per recipient at send.
const tpl = await bird.templates.create({
  name:    "order-confirmation",
  subject: "Order {{ order_number }} confirmed",
  html:    "<h1>Thanks, {{ first_name or 'there' }}.</h1>" +
           "{{ if is_member }}<p>You earned {{ points }} points.</p>{{ end }}",
  variables: [
    { key: "first_name",   type: "string", fallback: "there" },
    { key: "order_number", type: "string" },
    { key: "is_member",    type: "boolean" },
    { key: "points",       type: "number" },
  ],
});

// Send it. Bird fills in the blanks for each recipient.
await bird.email.send({
  from:      "orders@acme.com",
  to:        ["ada@example.com"],
  template:  tpl.id,
  variables: { first_name: "Ada", order_number: "A-1043", is_member: true, points: 120 },
});

Plus qu''un rechercher-remplacer.

Une vraie logique de gabarit, résolue côté Bird, par destinataire, à l''envoi.

  1. 01

    Conditions.

    Affichez un bloc uniquement quand une valeur s''applique, comme une note réservée aux membres ou une bannière de livraison gratuite, sans envoyer deux modèles différents.

  2. 02

    Boucles.

    Répétez une ligne pour chaque élément d''un tableau, pour qu''un seul modèle de confirmation de commande liste chaque article réellement acheté par le client.

  3. 03

    Valeurs par défaut.

    Repliez-vous sur une valeur sûre quand un champ est manquant, pour qu''un prénom vide ne parte jamais comme une salutation vide.

  4. 04

    Données imbriquées.

    Accédez à des objets structurés avec des chemins pointés, pas seulement des clés plates de premier niveau, pour que vos structures de données existantes s''intègrent directement.

  5. 05

    Types de variables riches.

    Les variables déclarées peuvent être des chaînes, des nombres, des booléens, des tableaux et des objets, ce qui rend possibles les boucles et conditions ci-dessus.

Créez-les comme vous travaillez déjà.

Envoyez du HTML brut avec une liste de variables déclarées via l''API, et vous avez un modèle fonctionnel, sans nouvel éditeur à apprendre. Vous préférez les composants ? Rendez vos modèles React Email en HTML et stockez le résultat. La seule chose à savoir : laissez les tokens de Bird sous forme de texte littéral dans le JSX afin qu''ils survivent au rendu et soient remplis à l''envoi, au lieu de figer une valeur lors du rendu React.

receipt.ts
React Email
import { render } from "@react-email/render";
import { Receipt } from "./emails/receipt";

// Author in React. Leave Bird's tokens as literal text so they
// survive the render and get personalized per recipient at send.
const html = await render(<Receipt firstName="{{ first_name }}" />);

await bird.templates.create({
  name:    "receipt",
  subject: "Your receipt",
  html,
  variables: [{ key: "first_name", type: "string", fallback: "there" }],
});

Versionnés, comme le reste de votre code.

L''édition se fait sur un brouillon et ne touche jamais ce qui est en ligne. La publication fige une version immuable et numérotée et la déploie ; si un changement tourne mal, revenez à une version antérieure et republiez-la. Les éditions concurrentes sont détectées plutôt qu''écrasées en silence, pour que deux personnes travaillant sur le même modèle ne se gênent pas. Chaque version porte une identité stable, ce qui permet au reporting par modèle d''attribuer correctement les ouvertures et les clics.

Gardez chaque marque cohérente.

Un kit de marque contient vos couleurs, votre typographie, vos espacements, votre logo et votre ton, et les applique à un modèle pour que le résultat vous ressemble visuellement et dans le ton sans restyler chacun à la main. Les kits vivent au niveau de l''espace de travail et un espace de travail peut en conserver plusieurs, car une marque mère, une sous-marque et votre simple courrier transactionnel veulent rarement le même look. Utiliser un kit est facultatif : un modèle qui n''en a aucun se replie sur des valeurs par défaut soignées.

Prévisualisez exactement ce qui sera envoyé.

Remplissez un modèle avec des valeurs d''exemple et voyez le message rendu avant que quiconque le reçoive. La prévisualisation passe par le même chemin de rendu que l''envoi réel, pour que ce que vous approuvez soit ce qui part, et non une approximation à peu près correcte qui dérive une fois les tokens et la logique résolus pour de vrais destinataires.

Vers où vont les modèles.

Le modèle de gabarit stocké est la fondation de ce qui vient ensuite : décrire un modèle dans un prompt et générer un brouillon à affiner, en construire un visuellement sans écrire de HTML, et laisser les agents de codage composer des modèles à votre image via MCP, plus une bibliothèque de modèles de départ pour commencer. Ils s''appuient sur le même modèle versionné et conscient de la marque, pas sur une voie distincte, donc l''API que vous intégrez aujourd''hui est celle qu''ils étendent.

Allez plus loin dans la documentation.

Découvrez comment les modèles s'intègrent au guide d'envoi, y compris le rendu de React Email, et câblez les événements d'e-mail et webhooks pour que les ouvertures et les clics remontent par modèle.

FAQ modèles

Suis-je obligé d''utiliser un éditeur visuel ?+
Non. Vous pouvez créer et gérer vos modèles entièrement via l''API : envoyez votre HTML avec une liste de variables déclarées, et référencez le modèle par son id à l''envoi. L''éditeur est une voie d''entrée, pas la seule.
En quoi un modèle stocké diffère-t-il du fait de transmettre du HTML à chaque envoi ?+
Un modèle stocké est référencé par son id et versionné, et sa personnalisation est rendue côté Bird à l''envoi. Vous n''envoyez donc que les valeurs propres à chaque destinataire, pas le corps entier à chaque fois, et la mise en page et la logique vivent à un seul endroit au lieu d''être reconstruites dans votre code à chaque appel.
Que peut faire la personnalisation au-delà du rechercher-remplacer ?+
Conditions, boucles sur des tableaux, champs imbriqués et valeurs par défaut par champ, le tout résolu par destinataire à l''envoi. Un bloc d''adhésion peut ne s''afficher que pour les membres ; une commande peut lister ses articles. La logique est stockée dans le modèle, donc une charge utile plate clé-valeur par destinataire suffit à la piloter.
React Email fonctionne-t-il ?+
Oui. Rendez vos composants React Email en HTML et stockez le résultat comme corps de modèle. Pour les valeurs propres à chaque destinataire, laissez les tokens de Bird sous forme de texte littéral dans le JSX afin qu''ils survivent au rendu et soient remplis à l''envoi, plutôt que de figer une valeur lors du rendu React.
Puis-je revenir en arrière sur un modèle que j''ai cassé ?+
La publication fige une version immuable et numérotée. L''édition se fait sur un brouillon et ne touche jamais ce qui est en ligne jusqu''à la publication, et vous pouvez revenir à n''importe quelle version publiée antérieure et la republier. Chaque version conserve une identité stable, ce qui permet au reporting par modèle d''attribuer correctement les envois.
Y a-t-il de la génération par IA ou un éditeur glisser-déposer ?+
C''est ce vers quoi nous construisons, pas ce qui sort en premier. L''API (HTML avec variables déclarées) et React Email sont les voies de création disponibles aujourd''hui ; un éditeur visuel, la génération de modèle à partir d''un prompt et une surface de composition par agent viennent par-dessus le même modèle de gabarit stocké.
Comment envoyer concrètement un modèle stocké ?+
L'appel d'envoi est inchangé : référencez le modèle par son id et transmettez les valeurs propres à chaque destinataire, et l'API d'envoi d'e-mails existante gère le reste. Il n'y a pas d'endpoint d'envoi de modèle distinct à apprendre.

Les modèles font partie d''une plateforme, pas d''un outil ponctuel.

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.

Commencez avec un seul canal.
Ajoutez les autres quand vous êtes prêt.

Une clé API de test est disponible immédiatement. L'accès production se débloque dès que vous ajoutez un moyen de paiement et vérifiez un expéditeur.

Vous utilisez Claude Code, Cursor ou Codex ? Copiez un prompt de configuration et votre agent installe la CLI Bird et les compétences pour vous. Choisissez le vôtre :

Cursor