Sent.dm APIでSMSとWhatsAppメッセージを高速に送信する方法

TL;DR / クイックアンサー

Sent.dm APIは、SMSとWhatsAppを横断するビジネスメッセージングのための単一の統合ポイントを提供します。SentとApidogを組み合わせることで、資格情報を環境に保存し、使い捨てスクリプトを書かずにリクエストをテストし、ウェブフックのペイロードを検証し、メッセージングのワークフローを1か所で文書化できます。

はじめに

ほとんどのメッセージングプロジェクトは、同じ場所でペースが落ちます。API自体は難しくありませんが、運用上の詳細がすぐに積み重なります。APIキー、送信者ID、テンプレートID、ウェブフックセキュリティ、チャネルルール、そして実際のメッセージを無作為に送信せずにすべてをテストする明確な方法が必要です。

Sent.dmが興味深いのはまさにそのためです。Sentは、SMSやWhatsAppのようなアプリベースのチャネル向けに、ルーティングと配信ロジックを単一の開発者向けインターフェースの背後で処理する統一されたメッセージングAPIとして位置づけられています。2026年3月26日にレビューされたSentの公開ドキュメントに基づくと、このプラットフォームにはアカウント認証、チャネル設定、テンプレートベースの送信、連絡先、ウェブフックイベント、およびテスト用のダッシュボードプレイグラウンドが含まれています。

💡

このセットアップをよりスムーズに進めたいなら、Apidogは強力なコンパニオンツールです。Sent APIリファレンスをインポートし、x-api-keyとx-sender-idのための再利用可能な環境を作成し、メッセージ作成とウェブフック処理に関するテストシナリオを構築し、完成したコレクションをチームと共有できます。このチュートリアルに沿って進めるには、Apidogを無料でダウンロードしてください。

ボタン

Sent.dm APIが解決すること

Sent.dmは、各プロバイダーごとに個別の統合を維持することなく、複数のメッセージングチャネルでユーザーにアプローチしたいチームのために構築されています。SMS API、WhatsAppのオンボーディング、チャネル固有のペイロード形式、配信監視を自分で結合する代わりに、Sentはその複雑さを1つのプラットフォームに抽象化します。

公式ドキュメントによると、製品のストーリーはシンプルです。

メッセージングワークフローのための単一のAPIベースURL
x-api-keyによるヘッダーベースの認証
x-sender-idを使用する送信者IDモデル
テンプレート駆動のアウトバウンドメッセージング
連絡先とオーディエンス管理
配信およびテンプレートイベント用のウェブフック
プラットフォーム層におけるインテリジェントなルーティングとフェイルオーバーの概念

メッセージングシステムはめったに「テキストを送信して次に進む」だけではないため、この組み合わせが重要です。また、次のようなものも必要です。

一貫性のあるペイロード構造
テンプレートを再利用する安全な方法
配信済み、失敗、またはキューに入れられたメッセージのイベント追跡
フロントエンドコードから機密情報を除外するテストワークフロー
開発者とQAチームメイトが実際に利用できるドキュメント

実際の大きな課題は次のとおりです。

Application -> Message API -> Channel Rules -> Delivery Events -> Retry / Status Logic

すべての部分が異なるツールにある場合、デバッグは遅くなります。これを防ぐ最も簡単な方法の1つは、ApidogのようなAPIプラットフォームで最初から全体のフローをモデル化することです。

Sent.dm APIの仕組み

Sentの公開ドキュメントでは、このプラットフォームはアプリとダウンストリームのメッセージングチャネル間のインテリジェントなミドルウェア層であると説明されています。その約束はシンプルです。アプリが1つのリクエストを送信すると、Sentはルーティングロジック、受信者のコンテキスト、チャネルの利用可能性に基づいて最適な配信パスを選択します。

開発者にとって最も重要な部分は、セットアップシーケンスと資格情報モデルです。

1. アカウントとコンプライアンスのセットアップ

公式のスタートガイドフローは、アカウント作成、KYC認証、ビジネス設定から始まります。これはオプションの雑務ではありません。メッセージング製品はコンプライアンスルール、送信者の評判、地域の制限に関わるため、Sentはアカウント認証をオンボーディングパスの一部としています。

2. チャネルのセットアップ

Sentのドキュメントでは、電話番号の選択とWhatsApp Businessへの接続方法を説明しています。ドキュメントでは、SMSとWhatsAppに同じ番号を使用することで、チャネル間でブランドのアイデンティティを一貫させることが推奨されています。

3. テンプレート

テンプレートはワークフローの核となる部分です。スタートガイドでは、最初のAPIリクエストを送信する前にテンプレートを作成するようにSentが指示しています。これは、テンプレートベースのメッセージングがここでは特殊なケースではなく、デフォルトのパスの一部であることを示す良い兆候です。

4. API資格情報

ドキュメントには2つの資格情報が示されています。

x-sender-id: YOUR_SENDER_ID
x-api-key: YOUR_API_KEY

v3 APIリファレンスでは、x-api-keyが必須の認証ヘッダーとして強調されています。スタートガイドの例には、メッセージリクエスト用のx-sender-idも含まれています。これを本番環境で実装する際は、Sentダッシュボードで現在のワークスペースとエンドポイントのバージョンに対し、正確なヘッダー要件を確認してください。ドキュメントにはv3リファレンスビューとv2メッセージ例の両方が示されているためです。

5. メッセージリクエスト

スタートガイドでは、次へのリクエストが示されています。

POST https://api.sent.dm/v2/messages/phone

次のようなJSONペイロードを伴います。

{
 "phoneNumber": "RECIPIENT_PHONE_NUMBER",
 "templateId": "TEMPLATE_ID"
}

これは、最初の実装ターゲットについて重要なことを教えてくれます。最も速いパスは、巨大なオムニチャネルオーケストレーションサービスを構築することではありません。テンプレートベースの送信を正しく設定し、リクエストと配信の挙動を確実に監視できるようになってからワークフローを拡張することです。

最初のSent.dm APIリクエストを送信する

テストしやすく、メンテナンスしやすい方法で最初のリクエストを構築しましょう。

cURLの例

curl -X POST "https://api.sent.dm/v2/messages/phone" \
 -H "x-sender-id: YOUR_SENDER_ID" \
 -H "x-api-key: YOUR_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
 "phoneNumber": "RECIPIENT_PHONE_NUMBER",
 "templateId": "TEMPLATE_ID"
 }'

JavaScriptの例

const response = await fetch("https://api.sent.dm/v2/messages/phone", {
 method: "POST",
 headers: {
 "x-sender-id": process.env.SENT_SENDER_ID,
 "x-api-key": process.env.SENT_API_KEY,
 "Content-Type": "application/json"
 },
 body: JSON.stringify({
 phoneNumber: process.env.TEST_PHONE_NUMBER,
 templateId: process.env.SENT_TEMPLATE_ID
 })
});

if (!response.ok) {
 throw new Error(`Sent request failed: ${response.status}`);
}

const data = await response.json();
console.log(data);

Pythonの例

import os
import requests

response = requests.post(
 "https://api.sent.dm/v2/messages/phone",
 headers={
 "x-sender-id": os.environ["SENT_SENDER_ID"],
 "x-api-key": os.environ["SENT_API_KEY"],
 "Content-Type": "application/json",
 },
 json={
 "phoneNumber": os.environ["TEST_PHONE_NUMBER"],
 "templateId": os.environ["SENT_TEMPLATE_ID"],
 },
 timeout=30,
)

response.raise_for_status()
print(response.json())

スタートガイドのドキュメントによると、成功した応答はHTTP 200とmessageIdを返します。このmessageIdは、Apidogテスト、アプリケーションログ、サポートワークフロー、およびウェブフック調整でキャプチャしたい値です。

ApidogでSent.dm APIをテストする

ここでは、Apidogが単なるリクエストランナー以上のものになります。リクエスト、変数、テストアサーション、ドキュメント、チームへの引き継ぎがすべて連携している場合、メッセージングAPIはより扱いやすくなります。

ステップ1: Sent環境を作成する

Apidogで、次のような変数を含む環境を作成します。

base_url = https://api.sent.dm
sender_id = YOUR_SENDER_ID
api_key = YOUR_API_KEY
template_id = YOUR_TEMPLATE_ID
test_phone = RECIPIENT_PHONE_NUMBER

環境変数を使用すると、すぐに3つのメリットが得られます。

本番環境の秘密情報を例にハードコーディングするのを避けることができます。
サンドボックス、ステージング、本番アカウントをより速く切り替えることができます。
チームメイトは、自分自身の安全な値で同じコレクションを再利用できます。

ステップ2: リクエストを一度構築する

Apidogで新しいリクエストを作成します。

- x-sender-id: {{sender_id}} - x-api-key: {{api_key}} - Content-Type: application/json

メソッド: POST
URL: {{base_url}}/v2/messages/phone
ヘッダー:
ボディ:

{
 "phoneNumber": "{{test_phone}}",
 "templateId": "{{template_id}}"
}

これにより、チームは正確なペイロードの形式、認証モデル、および期待される応答を1か所で検査できるため、一度きりのターミナルテストよりもすでに優れています。

ステップ3: アサーションを追加する

Apidogで、成功パスを検証するテストを追加します。

チェック例:

pm.test("Status is 200", function () {
 pm.response.to.have.status(200);
});

pm.test("Response contains a messageId", function () {
 const json = pm.response.json();
 pm.expect(json.messageId).to.exist;
});

これらのチェックは、些細な間違いを素早く見つけるのに役立ちます。APIの変更、資格情報のローテーション、またはテンプレートの問題後にリクエストがメッセージIDを返さなくなった場合、すぐにそれを確認できます。

ステップ4: シナリオに変換する

単一のリクエストからワークフローに移行すると、Apidogはさらに役立ちます。

メッセージを送信する
返されたmessageIdを保存する
セットアップがそのフローを公開している場合、ダウンストリームのステータスをクエリする
ウェブフックを通じて受信したメッセージイベントを比較する

これはメッセージングシステムにとって適切なレベルのAPIテストです。なぜなら、1つのPOSTの成功がビジネスフローが健全であることを意味するわけではないからです。承認、配信、再試行、イベントの一貫性も重要です。

ステップ5: ウェブフックの例を同じコレクションに追加する

送信リクエストが機能したら、チームが受信することを期待するウェブフックイベントの保存された例を追加します。これにより、アウトバウンドリクエストとインバウンドイベント処理を網羅する単一のコレクションが得られます。

たとえば、ウェブフックのペイロード例を保存し、次のようなフィールドを文書化できます。

{
 "field": "message.status",
 "messageId": "msg_123",
 "status": "delivered",
 "channel": "whatsapp"
}

これはすぐに効果を発揮します。バックエンドエンジニアはライブペイロードを保存された例と比較し、QAはイベント処理ロジックを検証し、サポートチームはログを深く掘り下げることなくメッセージの状態が何を意味するのかを理解できます。

ステップ6: 内部ドキュメントを公開する

チームにバックエンドエンジニア、QA、サポート、製品関係者が同じメッセージングフローに関わっている場合、Apidogのドキュメント層は時間を節約します。チャットでバラバラなcURLスニペットを共有する代わりに、次を含むクリーンな内部リファレンスを公開できます。

必須ヘッダー
ペイロードの例
エラー応答
ウェブフックイベントの例
環境に関する注意点

これは、「このスクリプトを実行して何が起こったか教えてください」よりもはるかに強力な引き継ぎです。

テンプレート、連絡先、ウェブフックを正しく処理する

最初のリクエストが200を返すのは始まりに過ぎません。実際の運用作業はその後から始まります。

テンプレート

Sentのオンボーディングフローでは、特にWhatsApp関連のメッセージングに関して、テンプレートが強く強調されています。これは、API実装がテンプレートをバージョン管理されたコンテンツとして扱い、一度ファイルにコピーされて忘れ去られるIDとしてではないことを意味します。

実用的なパターンは次のとおりです。

テンプレートIDを環境変数または設定に保持する
各テンプレートを目的、ロケール、承認ステータスでラベリングする
テストテンプレートをライブキャンペーンテンプレートから分離する
どのテンプレートがどのユーザージャーニーにマッピングされるかを文書化する

Apidogは、承認された各テンプレートの例示リクエストを作成し、より広範なAPIコレクションと一緒に保持できるため、ここで役立ちます。

連絡先

Sentのドキュメントでは、連絡先が主要な機能領域として取り上げられています。アプリケーションがすでに内部的にユーザーを保存している場合でも、メッセージングプラットフォームの連絡先オブジェクトは、オーディエンスレベルの操作、テンプレートターゲティング、および通信履歴に役立ちます。

連絡先同期ロジックを構築する場合は、これらのルールを早期に文書化してください。

どのシステムが信頼できる唯一の情報源であるか
電話番号がどのように正規化されるか
オプトインまたは同意状態がどのように保存されるか
連絡先がチャネルを変更したときに何が起こるか

これらは後で整理する詳細ではありません。最初から配信性とコンプライアンスに影響を与えます。

ウェブフック

Sentのウェブフックドキュメントは、実際の運用利用にとってプラットフォームの最も重要な部分の1つです。ドキュメントには、次のようなヘッダーを含むHMAC-SHA256署名検証が説明されています。

x-webhook-signature
x-webhook-id
x-webhook-timestamp

ドキュメントではまた、署名形式をv1,{base64_signature}と説明し、5分間のタイムスタンプウィンドウによるリプレイ保護を推奨しています。

これにより、クリーンな運用チェックリストが得られます。

生の要求本文を読み取る
解析する前に署名を検証する
古いタイムスタンプを拒否する
イベントを冪等的に処理する
素早く承認し、重い作業はバックグラウンドジョブに移動する

Expressのコンパクトな例は次のとおりです。

import crypto from "crypto";
import express from "express";

const app = express();

app.post("/webhooks/sent", express.raw({ type: "*/*" }), (req, res) => {
 const signature = req.header("x-webhook-signature");
 const webhookId = req.header("x-webhook-id");
 const timestamp = req.header("x-webhook-timestamp");
 const secret = process.env.SENT_WEBHOOK_SECRET;
 const rawBody = req.body.toString("utf8");

 const signedContent = `${webhookId}.${timestamp}.${rawBody}`;
 const expected = crypto
 .createHmac("sha256", Buffer.from(secret.replace(/^whsec_/, ""), "base64"))
 .update(signedContent)
 .digest("base64");

 if (signature !== `v1,${expected}`) {
 return res.status(401).send("Unauthorized");
 }

 const event = JSON.parse(rawBody);
 console.log("Received webhook event:", event.field);

 return res.sendStatus(200);
});

Apidogを使用してウェブフックのサンプルペイロードを保存し、期待されるイベントを文書化します。これにより、フロントエンド、バックエンド、およびQAチームが同じメッセージライフサイクルについて連携しやすくなります。

Apidogがこのワークフローに適合する理由

Sent.dmはメッセージング層を提供します。Apidogはそのメッセージング層を取り巻くワークフロー層を提供します。

実用的な違いは次のとおりです。

タスク	Sent.dm	Apidog
SMSとWhatsAppメッセージの送信	はい	いいえ、しかしそれを行うAPIをテストします
テンプレートと送信者の設定を管理	はい	関連するリクエストを文書化および検証
認証されたリクエストをテスト	プレイグラウンドを通じて基本	強力なリクエストビルダー、環境、アサーション、シナリオ
APIドキュメントをチームと共有	プラットフォームドキュメント	チーム向けコレクションと生成されたドキュメント
リクエストとレスポンスのフローをデバッグ	部分的	反復可能な検査とコラボレーションに適している
エンドツーエンドのテストシナリオを構築	メッセージングに特化	多段階APIワークフローテストに適している

チームがアプリケーションメッセージングのためにSentを評価している場合、ApidogはSentが意図しないレイヤーをカバーします。つまり、共同API設計、テスト、デバッグ、モック計画、ドキュメント作成を1つのワークスペースで行えます。

これは少なくとも3つの状況で役立ちます。

複数の開発者をオンボーディングしており、共有可能なリクエストコレクションが必要な場合
QAがカスタムスクリプトを書かずにメッセージングAPIを検証したい場合
バージョン変更、新しいテンプレート、またはウェブフックのペイロードをテストするための再現性のある場所が必要な場合

Sent.dmリクエストのテスト、メッセージング環境の安全な保存、そして最初のAPI呼び出しの成功を再利用可能なチームワークフローに変えるために、Apidogを無料でダウンロードしてください。

ボタン

高度なヒントと一般的な間違い

基本的なフローが機能したら、これらのプラクティスにより統合の信頼性が向上します。

ベストプラクティス

資格情報はサーバー側のみに保持してください。Sentのドキュメントでは、クライアント側コードでAPIキーを公開することに対して明示的に警告しています。
アプリケーションログとサポートツールでmessageIdを追跡してください。
ステージングと本番のテンプレートを分離してください。
すべてのウェブフックを処理する前に検証してください。
Apidog環境を使用して、本番資格情報とテスト資格情報を分離してください。

避けるべき一般的な間違い

200応答をイベントライフサイクルの開始ではなく、最終的な配信結果として扱う
複数のサービスでテンプレートIDをハードコーディングする
展開の遅い段階まで送信者IDの設定を無視する
電話番号の一貫した正規化を忘れる
他の誰も検査できないアドホックスクリプトで実際の資格情報を使用してテストする

トラブルシューティングのヒント

リクエストが機能しない場合は、次の点を順番に確認してください。

x-api-keyは有効でアクティブですか？
呼び出しているエンドポイントは、Sentワークスペースに表示されているバージョンと一致していますか？
そのリクエストパスにx-sender-idは必須ですか？
テンプレートは承認され、選択したチャネルで利用可能ですか？
正しい形式の電話番号に送信していますか？

Apidogは、失敗したリクエストを既知の良好な保存済みリクエストと数秒で比較できるため、ここで役立ちます。

Sent.dmの代替と比較

Sent.dmを評価している場合、おそらく直接プロバイダーとの統合、より広範なコミュニケーションプラットフォーム、または日常的なテストのためによく使われるPostmanのようなAPIクライアントも検討しているでしょう。主な違いは制御とシンプルさであり、テスト層は配信層と同じくらい重要です。

オプション	強み	トレードオフ
直接SMS + WhatsAppプロバイダー	きめ細かな制御	より多くの統合およびメンテナンス作業
Twilioスタイルのコミュニケーションスタック	広範なエコシステム	マルチチャネルオーケストレーションのためのより多くの可動部品
Sent.dm	チャネル抽象化による統合メッセージングワークフロー	Sentのプラットフォーム規則とドキュメント構造に依存
Sent.dm + Postman	おなじみのリクエストテストフロー	ドキュメント、設計、およびより広範なワークフローコラボレーションがより断片化される
Sent.dm + Apidog	統合メッセージングに加え、強力なAPIテスト、ドキュメント作成、コラボレーションワークフロー	1つではなく2つのツール

開発者のスピードを重視するチームにとって、最良のセットアップは「すべてを1つのツールで」ではないことがよくあります。それは、配信プラットフォームと強力なAPIコラボレーション層を組み合わせることです。すでにPostmanを使用している場合、ここでApidogを検討する最も強力な理由は、基本的なリクエスト送信ではありません。それは、環境、保存されたドキュメント、アサーション、モック計画、およびチームへの引き継ぎが1つのワークスペースで行えることです。

結論

Sent.dmは、個別のチャネル統合の代わりに、SMSとWhatsAppのための1つのプラットフォームを望むチームにとって便利なメッセージングAPIです。最大の利点は、単にメッセージを送信できることだけではありません。テンプレート、送信者ID、連絡先、およびウェブフックを中心に、より構造化された方法でテストおよび構築できることです。

より迅速に進めたい場合は、まずApidogで最初のSentリクエストを構築し、messageIdのアサーションを追加し、同じワークスペースでウェブフック契約を文書化することから始めます。これにより、散らばったスクリプトや暗黙の知識に頼るよりも、プロトタイプから本番環境へのよりクリーンなパスが得られます。

ボタン

よくある質問 (FAQ)

Sent.dm APIは何のために使われますか？

Sent.dm APIは、単一の統合を通じてSMSやWhatsAppなどのチャネルを横断するビジネスメッセージングに使用されます。公式ドキュメントによると、送信者の設定、テンプレート、連絡先、およびウェブフックベースのイベント処理をサポートしています。

Sent.dmはWhatsAppとSMSを単一のAPIでサポートしていますか？

はい。Sentはこのプラットフォームを、チャネル固有の複雑さを1つの開発者向け統合の背後に抽象化する統一されたメッセージングAPIとして位置づけています。オンボーディングドキュメントでは、SMSとWhatsAppで同じ電話番号を使用することも推奨されています。

Sent.dm APIリクエストにはどのヘッダーが必要ですか？

公開ドキュメントでは、x-api-keyが主要な認証ヘッダーとして示されており、スタートガイドのメッセージ例ではx-sender-idも使用されています。ドキュメントにはv3とv2の両方のリファレンスが示されているため、本番展開前にSentアカウントで正確なエンドポイントバージョンを確認してください。

Sent.dmでメッセージを送信する前にテンプレートが必要ですか？

スタートガイドのフローでは、はい、必要です。Sentのオンボーディングガイドでは、テンプレートを作成し、その後templateIdを使用して最初のメッセージを送信する手順が説明されています。

カスタムスクリプトを書かずにSent.dm APIをテストするにはどうすればよいですか？

Apidogはこれに適しています。Sentの資格情報を環境変数として保存し、メッセージリクエストを保存し、アサーションを追加し、多段階シナリオを構築し、ウェブフックペイロードを文書化し、チームの残りのメンバーのために内部APIドキュメントを公開することができます。

Sent.dmのウェブフックをどのように保護すべきですか？

HMAC署名を検証し、タイムスタンプを検証し、イベントを冪等的に処理してください。Sentのドキュメントには、検証のためにx-webhook-signature、x-webhook-id、およびx-webhook-timestampなどのヘッダーが説明されています。

Sent.dmだけでチームのAPIワークフローには十分ですか？

それはメッセージングプラットフォーム自体をカバーしますが、ほとんどのチームはテスト、ドキュメント作成、および繰り返しの検証のために共同APIツールを依然として必要としています。Apidogが価値を付加するのはそこです。