Emails transactionnels interactifs via l'API d'envoi

La plupart des expéditeurs d'emails transactionnels ne rendent que du HTML brut. POST /api/v1/send en mode modèle rend à la place l'un de vos propres projets studio — moteur d'alternatives complet et blocs interactifs inclus — avec mergeData se substituant à la ligne de valeurs dynamiques, si bien qu'un reçu ou un email de confirmation déclenché par votre backend peut porter un bloc Notation ou une vente incitative de Produit exactement comme le ferait un envoi marketing.

Objet

Your order receipt

La plupart des expéditeurs d'emails transactionnels ne rendent que du HTML brut. POST /api/v1/send en mode modèle rend à la place l'un de vos propres projets studio, moteur d'alternatives complet et blocs interactifs inclus. Un reçu ou une confirmation déclenché par votre backend peut porter un bloc Notation ou une vente incitative de Produit exactement comme le ferait un envoi marketing.

Un reçu est l'un des emails au taux d'ouverture le plus élevé qu'une entreprise envoie — et presque toujours le plus dépouillé, parce qu'il est généralement généré par la bibliothèque transactionnelle la plus simple à brancher, pas par quelque chose disposant d'un système de design.

Concevez-le une fois, déclenchez-le depuis votre backend

Construisez le reçu ou la confirmation comme un projet studio normal, avec les blocs qui font sens — une Notation pour un CSAT post-achat, une vente incitative de Produit d'article associé. Votre backend appelle ensuite l'API d'envoi en mode modèle avec l'ID du projet et un objet mergeData se substituant aux valeurs dynamiques de cette commande précise.

Marquez-le correctement comme transactionnel

Régler type sur "transactional" contourne la suppression par désabonnement — un reçu doit quand même atteindre quelqu'un qui s'est désabonné du marketing — mais jamais la suppression par rebond, puisqu'une adresse véritablement défaillante ne devrait pas continuer à recevoir des envois, quel que soit le type d'email.

C'est authentifié comme n'importe quelle intégration API

Une clé API nommée par propriétaire, authentifiée par Bearer, se génère et se révoque depuis la section Developers du tableau de bord. Un en-tête Idempotency-Key empêche une requête retentée d'envoyer le reçu deux fois.

Ce qui ne se reporte pas

Le mode libre (pas de projectId, seulement du html/text brut) saute entièrement le pipeline de rendu — pas de balises de fusion, pas de moteur d'alternatives, envoyé exactement tel que fourni. C'est le bon choix pour quelque chose comme un code OTP ponctuel ; le mode modèle est celui qui vaut la peine dès que l'email lui-même profite d'un bloc interactif.

Pour commencer

Construisez le modèle transactionnel comme un projet studio avec les blocs interactifs voulus, générez une clé API sous Developers, et appelez POST /api/v1/send en mode modèle avec votre mergeData et type: "transactional".

Une séquence type de création et d'envoi

  1. 1

    Construisez le modèle transactionnel comme un projet studio

    Concevez le reçu ou la confirmation une fois dans le studio, avec les blocs interactifs qui font sens — une Notation, un Produit d'article associé, un Bouton de statut.

  2. 2

    Générez une clé API

    Créez une clé API nommée sous Developers dans le tableau de bord — elle authentifie chaque appel de l'API d'envoi comme jeton Bearer.

  3. 3

    Appelez l'API d'envoi en mode modèle

    Votre backend fait un POST vers /api/v1/send avec l'ID du projet et un objet mergeData se substituant aux valeurs dynamiques de cette commande ou cet événement précis.

  4. 4

    Marquez-le comme transactionnel

    Réglez type sur "transactional" afin que l'envoi contourne la suppression par désabonnement (la suppression par rebond s'applique toujours) — la bonne sémantique pour un reçu dont le destinataire a besoin quelles que soient ses préférences marketing.

Questions fréquentes

Un email transactionnel envoyé via l'API peut-il inclure les mêmes blocs interactifs qu'une campagne ordinaire ?

Oui — le mode modèle rend un projet studio existant exactement comme le ferait renderEmail() pour tout autre envoi, si bien que chaque bloc et le moteur d'alternatives à trois niveaux complet se reportent à l'identique.

Comment les données par destinataire entrent-elles dans le modèle, puisqu'il n'y a pas de ligne de source de données pour un appel API ?

L'objet mergeData dans le corps de la requête se substitue à une ligne de source de données — jusqu'à 100 champs clé/valeur plats se résolvent dans les balises de fusion {{field}} du projet pour cet appel précis.

Quelle est la différence entre le type "transactional" et "marketing" sur le même endpoint ?

Le champ type contrôle quelle liste de suppression est vérifiée : transactional contourne la suppression par désabonnement (un reçu doit quand même atteindre quelqu'un qui s'est désabonné du marketing) mais jamais la suppression par rebond ; marketing respecte les deux.

Y a-t-il une limite de fréquence sur l'API d'envoi ?

Oui — 60 requêtes par minute par clé API, plus le même plafond mensuel de volume par propriétaire que partage chaque chemin d'envoi ; un en-tête Idempotency-Key empêche une requête retentée d'envoyer deux fois.

Puis-je envoyer un email HTML libre via le même endpoint plutôt qu'un projet studio ?

Oui — omettre projectId et envoyer directement html/text utilise le mode libre, envoyé tel quel sans pipeline de rendu ni balises de fusion ; c'est le mode modèle (avec projectId) qui porte les blocs interactifs et le moteur d'alternatives.

Construisez ceci dans le studio

Commencez avec le forfait gratuit : chaque bloc interactif et le moteur de repli complet sont inclus dans tous les forfaits.