送信先は公開 HTTPS を使用し、成功ステータスで迅速に応答するべきです。
SMSMobileAPI ›ソリューションガイド
SMS Webhookを受信
受信SMSを接続されたモバイルからあなたのアプリケーションにプッシュする
アカウントスコープの宛先、イベントフィルター、署名、ログ、自動再試行を備えて、受信SMSイベントをHTTPSエンドポイントに配信します。
- 互換性のあるモバイル端末
- お客様のSIMと番号
- API、ワークフローと統合
APIリクエストが受理されました
イベントアクティビティが同期
正確な問題点
ポーリングは遅延と不要なAPIトラフィックを生みます
返信が接続済み携帯に届いたとき、アプリケーションは繰り返し新しいメッセージを要求することなく反応すべきです。Webhook V2 は選択した HTTPS 宛先にイベントをプッシュします。
シンプルで見えるフロー
ビジネスイベントから有用な結果へ
一つの制御された連鎖があなたのソフトウェア、SMSMobileAPI、そしてあなたが所有するモバイルをつなぎます。
01
SMSがモバイルに到達
02
イベントが収集されました
03
署名付きHTTPS配信
04
お客様のアプリが応答します
40秒のデモ
受信 SMS がエンドポイントに届くのを監視する
シーケンスは自動的に繰り返されます。任意のステップで一時停止して自分のペースで確認できます。
00:40ガイド付きウォークスルー
-
1
購読
HTTPS送信先を追加し、received-SMS イベントを選択してください。
-
2
受信
連絡先が接続された携帯番号にSMSを送信します。
-
3
検証する
お客様のサーバーはJSONペイロードを信頼する前に署名を検証します。
-
4
処理する
成功ステータスを素早く返し、その後は非同期で処理を続行します。
実際のビジネス事例
例：顧客の返信をヘルプデスクの更新に変換する
顧客が配達メッセージに返信します。Webhook V2 がイベントをヘルプデスクのミドルウェアに投稿し、電話番号に一致させて返信をチケットに追加し、担当エージェントに通知します。
結果: ポーリングループなしでほぼリアルタイムのインバウンド処理。正直な制約
スケールする前に運用条件を把握する
物理的な携帯アーキテクチャは、その実際の制約を設計に組み込むと強力です。
Webhook の署名を常に検証し、イベント処理を冪等にしてください。
配信はモバイルアプリに許可が与えられ、受信SMSチャネルが有効になって初めて開始されます。
構築方法を選択
一つのモバイルプラットフォーム、複数の実装パス
チームに合った最もシンプルな経路から始め、ワークフローが成長したら機能を組み合わせてください。
このユースケースのための質問
よくある質問
エンドポイントが一時的に利用不可の場合はどうなりますか？
配信失敗は自動的に再試行され、専用の配信ログに表示され続けます。
1つのアカウントで複数のWebhook URLを使えますか？
はい。複数の宛先を作成し、各イベントタイプが受け取る宛先を正確に選べます。
応答前に時間のかかる処理を行うべきですか？
いいえ。イベントを検証して保存し、すばやく成功を返してから、長時間かかる処理は非同期で行ってください。
1つの管理されたテストから始める
電話を接続し、実際のメッセージでワークフローを検証してください。
アカウントを作成し、1台の対応モバイルをペアリングして、スケール前に経路全体を検証してください。
