ほとんどのトランザクションメール送信サービスは、プレーンなHTMLしかレンダリングしません。テンプレートモードのPOST /api/v1/sendは代わりに、自分自身のスタジオプロジェクトの1つを、フォールバックエンジンとインタラクティブブロックを含めてレンダリングします。バックエンドが発火させるレシートや確認メールは、マーケティング送信とまったく同じように、評価ブロックや商品のアップセルを載せられます。
レシートは、企業が送信するメールの中でも開封率が最も高いものの1つです — そして、ほとんどの場合最もそっけないものでもあります。デザインシステムが結び付いた何かではなく、たいてい配線が最も簡単だったトランザクションライブラリで生成されるからです。
一度デザインし、バックエンドから発火させる
レシートや確認メールを、普通のスタジオプロジェクトとして、意味のあるブロックを組み合わせて構築します — 購入後のCSATのための評価、関連商品の商品アップセルなどです。その後、バックエンドが、プロジェクトのIDと、その特定の注文の動的な値の代わりとなるmergeDataオブジェクトを添えて、テンプレートモードで送信APIを呼び出します。
正しくトランザクションとしてマークする
typeを"transactional"に設定すると、配信停止サプレッションを回避します — マーケティングを配信停止したユーザーにもレシートは届く必要があるためです — しかしバウンスサプレッションは決して回避しません。本当に不良なアドレスには、メールの種類にかかわらず送り続けるべきではないからです。
他のAPI連携と同じように認証される
アカウントごとの名前付きAPIキーがBearer認証を行い、ダッシュボードの開発者セクションから発行・取り消しできます。Idempotency-Keyヘッダーは、再試行されたリクエストがレシートを二重に送信するのを防ぎます。
引き継がれないもの
自由形式モード(projectIdなしで、生のhtml/textのみ)は、レンダリングパイプラインを完全にスキップします — マージタグもフォールバックエンジンもなく、与えられたとおりにそのまま送信されます。ワンタイムのOTPコードのようなものには、これが正しい選択です。メール自体がインタラクティブブロックの恩恵を受けるようになったら、テンプレートモードを使う価値が出てきます。
はじめに
トランザクション用のテンプレートを、望むインタラクティブブロックとともにスタジオプロジェクトとして構築し、開発者セクションでAPIキーを発行し、mergeDataとtype: "transactional"を添えて、テンプレートモードでPOST /api/v1/sendを呼び出します。