2026-10-12 訂正：送信endpoint、text_part、宛先toの形式、Bearer tokenの生成方法を公式APIへ合わせました。「確実に届く」「国内到達率最強」「n8nでserverless」という断定を修正しました。不達Webhookは公式に存在する機能です。
配信依頼と、到達・不達の確認を分ける
blastengineの送信APIをn8nから呼び、配信IDと不達eventを照合する設計例です。n8nのHTTP Request nodeを使う構成は可能ですが、hostや実行環境の選択なしにserverlessになるわけではありません。
今回行ったのは公開仕様と合成データの検証です。アカウント作成、API keyの取得・変更、メール送信、Webhook有効化、Slack通知は行っていません。到達率の比較測定や即時発行の条件も未確認です。
1. 正しいendpointとbodyを使う
blastengine公式API referenceのtransaction配信は、POST https://app.engn.jp/api/v1/deliveries/transactionです。JSONの例は次のとおりです。アドレスは架空で、登録・認証済みの送信元を用意した例ではありません。
{
"from": {
"email": "sender@example.com",
"name": "架空の送信元"
},
"to": "recipient@example.com",
"subject": "架空の受付通知",
"text_part": "お問い合わせを受け付けました。",
"encode": "UTF-8"
}
本文のキーはtext_part、一件のtransaction配信のtoは宛先文字列です。旧稿のtext_contentとオブジェクト配列は、このAPIの契約と合いません。別の一斉配信APIの形式を混ぜず、fieldと制限を確認します。
n8nではHTTP Request nodeのmethod、URL、JSON body、認証headerを採用版へ合わせます。送信元、テンプレート、宛先の決定を外部入力へ無制限に任せません。フォームに入力された任意アドレスへメールを送る入口は、spam・大量送信・費用の制御が必要です。
2. API keyとBearer tokenを混同しない
同referenceの認証手順は、ログインIDとAPI keyを連結し、SHA-256の小文字hex文字列をBase64にしたtokenを使います。raw digestのbyte列を直接Base64にする手順ではありません。
以下はNode.jsの純粋な生成関数です。実際の秘密情報を記事・console・実行ログへ出さず、適切なcredential管理へ渡します。このコードを掲載したことは、n8n Code nodeのcrypto利用を確認したことでもありません。
import {createHash} from 'node:crypto';
export function makeBearerToken(loginId, apiKey) {
if (typeof loginId !== 'string' || !loginId || typeof apiKey !== 'string' || !apiKey) {
throw new Error('credentials missing');
}
const hex = createHash('sha256').update(loginId + apiKey, 'utf8').digest('hex');
return Buffer.from(hex, 'utf8').toString('base64');
}
Authorization: Bearer <token>を使います。ログイン用passwordを取得すれば送れるという旧稿の説明は使いません。tokenはcredential相当の秘密です。管理画面の発行・再発行やn8nのcredential作成・変更は、この確認作業では行っていません。
3. delivery_idを保存し、送信結果を照合する
APIの受付と、受信側の到達・受信箱への配置・開封は同じではありません。返されたdelivery_idを自分の受付ID・宛先・テンプレート版へ対応させ、配信詳細やeventを確認します。
通信断やtimeoutでは配信IDの応答を受け取れなくても、受付済みの可能性があります。即時に同じ送信を繰り返さず、ログや取得できる状態を照合して、結果不明として判断します。上流の受付重複と、workerの同時実行にも対策が必要です。
SPF、DKIM、DMARC、送信元設定、停止リスト、rate limit、本文・URL、配信量を確認します。正しいAPI bodyだけで、すべてのキャリア・受信者に必ず届く保証はありません。導入判断は実際の対象・条件で比較します。
4. 不達Webhookを受信し、通知の成功も確認する
公式Webhook設定では、transaction等の不達情報をHTTP POSTで通知できます。event typeの意味を確認し、一時的なエラーと停止リスト・恒久的な不達を同じ再送扱いにしません。
受信endpointは認証し、本文サイズ、field、配信IDと自分の記録の対応を検証します。設定できる認証方式は公式実装案内で確認します。Basic認証等の秘密をURLやログで露出させない運用も必要です。未確認の署名headerを独自に仮定しません。
eventの重複・遅延・順序、受信失敗、受付保存、再処理を設計します。Slack通知が失敗した場合も不達記録を失わず、メール送信を再実行しないよう段階を分けます。通知へ宛先や原文を出す範囲は閲覧権限に合わせます。
5. 検証する範囲を決める
まず架空データでbodyとtoken生成を確認し、その後は明示的に許可したtest宛先・送信元だけで、配信ID、詳細、不達、通知、再送を検証します。大量送信や実顧客への送信を、設定確認の一部として始めません。
今回は掲載JSONをparseし、token生成の正常・空値・型不正を合成入力で確認しました。API認証、実配信、DNS、n8n、Webhook、停止リスト、Slackと到達率は未検証です。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。