配信、バウンス、開封、クリック、苦情のすべてについて署名付きイベントを受信し、取りこぼした分は再送できます。
AIがイベントストリームを要約し、異常なバウンスのパターンを検出次第お知らせします。
配信済み、保留、バウンス、開封、クリック、苦情、配信停止。
すべてのリクエストがMigoSMTPからのものであることを検証。
失敗した配信は自動で再試行されます。
障害後に、ログからイベントを再送できます。
必要なイベントだけを購読できます。
すべての試行について、リクエスト、レスポンス、ステータスを確認できます。
HTTPSのURLを入力し、イベントを選択します。
各リクエストの署名ヘッダーを確認します。
2xxレスポンスを返して受信を通知します。
ステージを切り替えて、各段階でコントロールできる内容を確認できます。イメージ画面です。表示されている数値とアドレスはすべてサンプルデータです。
ポーリングなしで、データベースの更新、ワークフローの起動、チームへの通知ができます。
メールのwebhookは、送信したメッセージに何かが起きたときにアプリケーションへ通知するHTTPコールバックです。MigoSMTPは、配信済み、保留、バウンス、開封、クリック、苦情、配信停止などのイベントについて、署名付きJSONペイロードをHTTPSエンドポイントにPOSTします。システムはAPIに繰り返しステータスを問い合わせる代わりに、即座に反応できます。ペイロードには、メッセージID、受信者、イベントタイプ、タイムスタンプ、失敗の場合は受信サーバーが返した理由が含まれます。これらのフィールドにより、追加の問い合わせや推測なしで、イベントを自社のレコードと突き合わせられます。
エンドポイントを登録し、受信するイベントを選び、各リクエストの署名ヘッダーを検証します。受信を確認するには2xxレスポンスを返してください。エンドポイントが失敗した場合、配信はバックオフ付きで再試行され、障害後にはログからイベントを再送できます。すべての試行のリクエストとレスポンスの詳細が保存されるため、すばやくデバッグできます。シークレットはローテーションでき、イベントフィルターで各エンドポイントの用途を絞り込めます。失敗した試行にはリクエスト、レスポンス、時刻が表示されるので、ハンドラーのデバッグを根拠に基づいて手早く行えます。
イベントデータは、送信システムが学習するための材料です。抑止リストの更新、苦情の急増時のキャンペーン停止、領収書メールのバウンスのサポートへの通知は、いずれもタイムリーなイベントに依存します。当社のAIレイヤーは大量のストリームを要約して異常なパターンを検出できるため、お客様から連絡が来てからではなく、数分以内に問題に気づけます。再送機能とログがあるので、自社システムで生じた抜け漏れがデータの欠落になることはありません。
配信されたら注文を通知済みにし、ハードバウンスが届いたらコンタクトにフラグを立てます。webhookならポーリングジョブが不要になり、アプリケーションの状態を正確に保てます。
バウンスまたは苦情のイベントを受けたら、そのアドレスを自社の送信禁止テーブルにすぐ追加すれば、同じ相手にメールを送る他のシステムも送信を停止します。
パスワードリセットのメールがバウンスしたら、SlackやチケットでアラートをPOSTします。お客様が諦める前に、サポートが別の手段で連絡できます。手作業にかかる何時間もの手間を省けます。
デプロイ中にエンドポイントがオフラインだった場合は、ログから未受信のイベントを再送し、レコードを正しい状態に戻せます。その間に失われるものはありません。
配信イベントが届いたらすぐに、注文を通知済み、サポートチケットを回答済みにできます。
イベントを自社の分析基盤にストリーミングし、メールの成果をプロダクトや売上のデータと並べて確認できます。
どちらもイベントデータを取得できます。適した状況が異なります。
webhookでリアルタイムに更新を受け取り、取りこぼした分はAPIで補完しているチームが多くあります。
コパイロットが数千件のイベントを短いダイジェストにまとめます。どのプロバイダーが保留しているか、どのキャンペーンが苦情を招いているかなどを、それぞれの根拠となるメッセージへのリンク付きで示します。
モデルが通常のバウンス率、苦情率、保留率を学習し、ストリームが通常から外れるとアラートを出します。通知先や自動化の実行有無は、お客様が設定します。
失敗した配信ログを貼り付けると、署名の不一致やタイムアウトなど考えられる原因をアシスタントが説明し、試すべき修正案を提示します。変更を行うのはお客様です。
MCPサーバー経由で、AIエージェントは読み取り専用スコープでイベント履歴と配信ログを参照できます。書き込み操作には明示的なスコープが必要で、ご希望なら人による承認も必須にできます。
AI機能はあくまで支援です。要約とアラートを行い、自動アクションはチームが設定・承認したものに限られます。
署名ヘッダーが一致しないリクエストは拒否しましょう。シークレットは定期的にローテーションし、漏洩の可能性がある場合はただちに変更してください。
ペイロードを安全に保存できたらすぐに2xxで応答し、処理はキューから行います。ハンドラーが遅いと、タイムアウトや重複した再試行の原因になります。
配信は重複したり、順序が前後したりすることがあります。メッセージIDとタイムスタンプを使って重複を排除し、古い状態変更は無視しましょう。
エンドポイントごとにイベントをフィルターしましょう。無関係なリクエストが減れば、サーバーの負荷が下がり、監視もシンプルになります。連携をスリムに保てば、デバッグも素早く行えます。
配信ログで失敗が繰り返されたらアラートを出しましょう。無音の障害は、誰かが欠落分を再送するまで、データのずれが気づかれないまま進むことを意味します。
2xxレスポンスをすばやく返し、重い処理はキューに移して、ハンドラーが遅くても再試行が発生しないようにしましょう。
エンドポイントの接続でお困りですか?公開前に、私たちのチームが一緒に確認します。
メールのwebhookとは、メッセージの配信やバウンスなどのイベントが発生したときに、メールプロバイダーがお客様のサーバーへ送るHTTPリクエストです。APIを繰り返し確認しなくても、アプリケーションがリアルタイムで反応できます。ポーリングジョブが不要になり、レコードを常に最新に保てます。
各リクエストには、エンドポイントのシークレットで生成された署名ヘッダーが含まれます。受信側で生のリクエストボディから署名を再計算して比較し、一致しなければリクエストを拒否してください。ドキュメントにコードサンプルがあります。
配信済み、保留、バウンス、開封、クリック、苦情、配信停止です。エンドポイントごとに一部のイベントだけを購読できるため、あるサービスにはバウンス、別のサービスにはエンゲージメントイベントを送れます。抑止にはバウンス、分析にはクリックなど、システムが対応するものだけを選べば、エンドポイントへのトラフィックを少なく、必要なものに絞れます。
失敗した配信はバックオフ付きで再試行され、復旧後にログからイベントを再送できます。リクエストとレスポンスを含むすべての試行が記録されるため、何が失敗したかを確認できます。ハンドラーがすばやく応答を返し、失敗をログに記録していることを確認してください。
厳密な順序には依存しないでください。メッセージIDとタイムスタンプを使い、重複や順序の乱れに耐えるハンドラーを作りましょう。イベントの順序はプロバイダーや再試行によって前後することがあり、1通のメッセージから複数のイベントが生じる場合もあります。
一部のメールシステムは画像を自動的に取得するため、誰もメッセージを読んでいなくても開封として記録されます。可能な範囲で人による開封と区別していますが、開封トラッキングはあくまで推定値です。開封は大まかな指標として扱い、クリックや返信をエンゲージメントのより強いシグナルとして数えてください。
ダッシュボードからサンプルイベントをURLに送信し、ハンドラーが署名を検証して2xxを返すことを確認します。配信ログでリクエストと自社のレスポンスを確認してください。本番の前に、テスト用シークレットを使ったステージングのエンドポイントで試しましょう。エンドポイントを本番に向ける前に必ず実行してください。
AIは、イベントストリームの要約、異常なバウンスや苦情のパターンの検出、失敗した配信のデバッグを支援できます。アクションを推奨しますが、ルールを設定しない限り、お客様の設定を変更することはありません。新しいエンドポイントを接続する前に、最近のログを確認してください。
ダッシュボードからサンプルイベントを送信します。
重複や順序の乱れに耐えるハンドラーを作り、メッセージIDとタイムスタンプで重複を排除してください。