RCSデバイスの能力チェック
ターゲット・デバイスがRCSメッセージング機能をサポートしているかどうかを確認するために、ケイパビリティ・チェックを実行することができる。現在、デバイスのケイパビリティ・チェックを実行する方法は2つある：
注：デバイスによっては、本来RCSメッセージングをサポートできるが、ユーザがその デバイス上でその機能を有効にしていない場合がある。本文書では、「RCS到達可能」という用語は、RCSに対応し、かつその機能が有効になっているデバイスを示す。
個別機器の能力チェック
チェックは GET リクエストを以下のURLに送る：
https://api.nexmo.com/v1/channel-manager/rcs/agents/{vonage_id}/google/phones/{phone_number}/capabilities
必要なパスパラメーターは2つある：
vonage_id.これはRCSエージェントの送信者IDであり、RCSエージェントの一部として提供されます。 RCSのセットアップとオンボーディング・プロセス.phone_number.能力チェックの対象となるデバイスの Numbers。
A Authorization ヘッダーがリクエストの一部として必要である。このヘッダーの値には、以下の形式の有効なJWT（JSON Web Token）を含める必要があります。 Bearer ${JWT}.JWTは、RCS送信者IDが関連付けられているVonageアプリケーションのアプリケーションIDと秘密鍵を使用して作成できます。以下を参照してください。 認証 を参照してください。
参照 チャネルマネージャAPI仕様 このエンドポイントの技術的な詳細については
注：個々のデバイスの能力チェックは、テストエージェント（そのエージェントのために許可リストに登録された番号）、またはライブエージェント（エージェントが開始された国でサポートされているネットワークに接続されている番号）のいずれかで実行することができます。
リクエスト例
以下は、ケイパビリティ・チェック・エンドポイントへのcURLリクエストの例である：
curl --location 'https://api.nexmo.com/v1/channel-manager/rcs/agents/VonageBasic/google/phones/447900000000/capabilities' \
--header 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJ...'
回答
200 OK
デバイスがRCS到達可能であれば 200 OK HTTPレスポンスを受信する。レスポンス・ボディには、デバイスがサポートするRCS機能の配列が含まれる：
{
"features":
[
"RICHCARD",
"RICHCARD_CAROUSEL",
"CREATE_CALENDAR_EVENT",
"DIAL_PHONE_NUMBER",
"OPEN_URL",
"SHARE_LOCATION",
"VIEW_LOCATION"
]
}
400 バッドリクエスト
にはさまざまな事情がある。 400 Bad Request エージェント送信者IDが有効でない、またはチェックされた電話番号が無効な形式であるなどのHTTPレスポンスを受信します。
403禁
テストエージェントを使用していて、そのエージェントのために番号が許可リストに登録されていない場合、またはライブエージェントを使用していて、そのエージェントが立ち上げられた国でサポートされているネットワークに接続されていない場合。 403 Forbidden HTTPレスポンスを受信する。
404 見つかりません
デバイスがRCS到達可能でない場合は 404 Not Found HTTPレスポンスを受信する。
バルク・デバイスの能力チェック
チェックは POST リクエストを以下のURLに送る：
https://api.nexmo.com/v1/channel-manager/rcs/agents/{vonage_id}/google/{operation}
必要なパスパラメーターは2つある：
vonage_id.これはRCSエージェントの送信者IDであり、RCSエージェントの一部として提供されます。 RCSのセットアップとオンボーディング・プロセス.operation.RBMエージェントが実行する操作。この場合users:batchGet.
A Authorization ヘッダーがリクエストの一部として必要である。このヘッダーの値には、以下の形式の有効なJWT（JSON Web Token）を含める必要があります。 Bearer ${JWT}.JWTは、RCS送信者IDが関連付けられているVonageアプリケーションのアプリケーションIDと秘密鍵を使用して作成できます。以下を参照してください。 認証 を参照してください。
A Content-Type ヘッダーはリクエストの一部として必須である。ヘッダーの値は application/json.
リクエストは、1つのプロパティを持つJSONボディを含まなければならない： users.これは 配列 一括検査中にサンプリングされる電話番号を表す文字列。
個別の能力チェックとは異なり、一括チェックではサポートされている機能のリストは返されません。RBMに到達可能なユーザー数を推定するには、一括能力チェックを行います。一括チェックでは、電話番号が到達可能かどうかは示されますが、どの機能をサポートしているかは示されません。
- 各バルクチェックには、500～10,000のユニークな電話番号を含める必要があります。それ以上の場合は、複数回チェックを行ってください。
- また、500未満のリクエスト、10,000以上のリクエスト、重複したリクエストはエラーとなります。
- 一括チェックは、あなたのエージェントがローンチされたキャリアで到達可能な番号のリストと、すべてのキャリアで到達可能なユーザーの合計の見積もりを返します。
リーチ可能なユーザー総数の見積もり
一括チェックの回答には、エージェントが立ち上げたキャリアですぐに連絡の取れる電話番号のリストが含まれるが(reachableUsers)、レスポンスには、全キャリアにわたる到達可能なユーザーの総数を推定するのに役立つ2つの値も含まれる。
どのように機能するか
- RBMは、一括能力検査(
totalRandomSampleUserCount). - RBMはまた、サンプルからRBMリーチ可能な数のカウントを返す(
reachableRandomSampleUserCount). - 分割することによって
reachableRandomSampleUserCountによってtotalRandomSampleUserCount全キャリアで展開した場合、あなたのエージェントが到達できるNumbersのパーセンテージを見積もることができます。
例
あなたが5,000の電話番号を提出した場合、RBMは無作為に3,750をサンプリングすることができます。そのうち3,000件が到達可能であれば、サンプリングされた番号の80％が到達可能であったことになる。
参照 チャネルマネージャAPI仕様 このエンドポイントの技術的な詳細については
注意: バルクデバイス能力チェックは、ライブエージェントでのみ実行可能で、この場合、エージェントが起動された国でサポートされているネットワークに接続されている番号に対してのみ実行可能です。テストエージェントで実施した場合、チェック対象の番号がRCS対応であっても、応答は空のオブジェクトとなります。
リクエスト例
以下は、ケイパビリティ一括チェック・エンドポイントへのcURLリクエストの例である：
curl -X POST https://api.nexmo.com/v1/channel-manager/rcs/agents/VonageBasic/google/users:batchGet \
-H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJ..." \
-H "Content-Type: application/json" \
-d '{
"users": [
"34613994828",
"34613994829"
]
}'
回答
200 OK
{
"reachableUsers": [
"34613994828",
"34613994829"
// rest of reachableUsers list
],
"totalRandomSampleUserCount": 632,
"reachableRandomSampleUserCount": 324
}
400 バッドリクエスト
にはさまざまな事情がある。 400 Bad Request エージェント送信者IDが有効でない、またはチェックされた電話番号の1つ以上が無効な形式であるなどのHTTPレスポンスを受信します。