サポートされるシナリオ
トランザクションアラートは、次のような重要なユーザーコミュニケーション向けに設計されています。- 注文/予約/購入の確認
- 発送/配達の確認と更新
- セキュリティおよびアカウントに関するアラート
- パスワードのリセット
- OTP（ワンタイムパスワード）
- ユーザーの招待と共有
- 以前のトランザクションに関連するユーザーの未実施アクション
- 不正防止/セキュリティアラート
- SMS、Email、Push などの単一チャネルでトランザクションメッセージを送信する。
- 複数のチャネルでトランザクションメッセージを送信する。
エンドポイント
Inform API は、次のエンドポイントで構成されています。用語集
以下は、Inform API を使用する際に出てくる用語の一覧です。Live 環境と Test 環境
環境に応じた正しい ID とエンドポイントを使用していることを確認してください。
Inform API の動作とレスポンス
Inform API は、次の 2 つのステップで動作します。- Inform に対して受信した API リクエストが有効かどうかを確認するチェックが行われます。
- 有効な場合、2 番目のプロセスとしてコンテンツを解決し、パートナーを使用してメッセージを送信します。
レスポンスコード
レスポンスコードは、次に説明する wxyzab 形式で返されます。- w - ステータス（失敗は 1、成功は 2 で示されます）。
- x - エラーのカテゴリ。
- y - リクエストが並列リクエストとして扱われるかどうか（並列リクエストは 0、フォールバックリクエストは 1 で示されます）。
- z - このリクエストを再試行できるかどうか（0 は同じ詳細情報では再試行できないことを示します）。
- ab - エラーの理由の詳細。
理由の詳細は次のとおりです。各理由コードには特定の意味があります。
API リクエスト受け付け前のペイロードエラー
API リクエストの受け付け前に発生する可能性があるペイロードエラーと、各機能のさまざまなシナリオで HTTP ステータスコード 4xx とともに返される対応するレスポンスコードの一覧は次のとおりです。API リクエスト受け付け後のペイロードエラー
アラートは、次のように並列/順次フォールバック用に設定できます。- 並列: 並列リクエストの場合、成功/失敗したリクエストのペイロード情報は各チャネルレベルで追加されます。
- 順次: フォールバックリクエストの場合、成功/失敗したリクエストのペイロード情報は最初のチャネルについて追加され、その他のチャネルの情報は Streams を通じて共有されます。
よくある質問
重複したリクエストはどのように処理されますか？
重複したリクエストはどのように処理されますか？
次の場合、リクエストは重複とみなされます。
- 同じ transaction_id を含む以前の成功したリクエストから 5 分以内に受信された場合
- 同じ transaction_id を含み、“In Progress”（処理中）の以前のリクエストから 5 分以内に受信された場合
ベンダーが MoEngage からのリクエストを受け付けない場合はどうなりますか？
ベンダーが MoEngage からのリクエストを受け付けない場合はどうなりますか？
ベンダーが MoEngage からのリクエストを受け付けない場合、MoEngage は 200ms の指数バックオフで各リクエストを最大 5 回再試行します。
アラートログは MoEngage に保存されますか？
アラートログは MoEngage に保存されますか？
MoEngage では、すべてのアラートについてアラートログが最大 30 日間保存されます。
"Live Alert Request received on Sandbox API endpoint" というエラーが発生するのはなぜですか？
"Live Alert Request received on Sandbox API endpoint" というエラーが発生するのはなぜですか？
このエラーは、Live のアラート ID を Sandbox エンドポイントに送信した場合に発生します。各アラートには 2 つの ID（Live 用と Test 用）があり、MoEngage ダッシュボードのテスト環境で作成されたアラートでも同じ動作になります。Test Alert ID は、アラートを編集して 3 ページ目に移動すると確認できます。