- ホーム
- /
- 投稿記事
Webex Calling マルチテナント(MT)パートナーは、Webhookを設定してすべての顧客の Webex Calling レコードを収集できます。これにより、各顧客に個別に問い合わせることなく、効率的な請求照合、分析、レポートが可能になります。
概要
Detailed Call Recordsウェブフックは、 リクエストではなくイベントによって駆動される安全でスケーラブルで堅牢なソリューションを提供します。 このウェブフックは、 Webex Calling顧客の活動を可視化して、請求からカスタムメイドのレポートまで、さまざまなユースケースをサポートします。
このWebhookを使用すると、 Partner Hubで管理しているすべての顧客の記録を、各顧客に個別に問い合わせることなく便利に収集できます。 このウェブフックを使用すると、 社内のビジネス要件と付加価値サービスの両方に対応したカスタムレポート、請求、分析アプリケーションを開発できます。
Webhookとそれに付随するAPIの概要については、こちらのVidcast:Webex Callingパートナー詳細通話履歴APIをご覧ください。
パートナーウェブフックが提供するもの
Webhookは、詳細な通話履歴記録を5分ごとに配信します。 各Webhookペイロードには以下が含まれます:
- 現在の時刻の10分から5分前に終了した通話記録。
- Webex Callingクラウドで処理されたすべての遅延記録。
- 信頼性の高い配信を確保するために、後続のWebhookペイロードにレイトコール記録を自動的にバックフィルします。
通話記録が各ペイロードにどのように含まれるかを示すには、次の例を考えてみましょう。
- 14:05 に受信したペイロードには、13:55 から 14:00 の間に終了した通話が含まれています。
- 14:00 から 14:05 の間に終了した通話は 14:10 のペイロードに含まれます。
- 以前に完了した記録(たとえば、14:04 に終了した通話) Webex Callingがクラウドによって遅れて処理された(たとえば 14:11 に)記録は、次に予定されているペイロード(たとえば 14:15)に含まれます。
ウェブフックは確実に記録を配信します。 ただし、システムが特定の条件下でレコードを再生すると、 後続のWebhookペイロードで重複したレコードを受け取ることがあります。 記録の重複排除の処理はあなた次第です。 重複するレコードを識別するには、 reportIdフィールドを主キーとして使用し、 reportTimeフィールドを使用して通話が完了または処理されたかを判断します。 これらのフィールドを使用して、レコードを更新したり、 内部データストアに挿入したりします。
パートナーハブのWebhook
Webhookを提供することで、分析プラットフォームが通話記録を生成するたびに、コールバックURLに通話記録を送信できるようになります。
Webex Calling記録は、既存の詳細通話記録APIと同じ形式で配信されます。 Webhookを設定して、次の2種類のフィードから選択できます。
- 分析-パートナーが関係のあるすべての顧客組織のすべての通話記録が含まれます。Webex Calling これには、次のような組織が含まれます。
- パートナーは、パートナーのフルアドミニストレータの役割で顧客組織を管理します。
- 顧客組織は、Webex Callingパートナー組織内で有効なサブスクリプションを持っています。
- 請求-Webex Calling パートナーが販売・提供したライセンスを持つユーザーによる通話記録が含まれます。 このフィードには、ワークスペースの通話記録が含まれています。
アクセスとデータプライバシー
通話詳細記録(CDR)にアクセスして請求できるのは、オーナーパートナーだけです。
- 通話記録に関連するライセンスを管理するパートナー(またはサブパートナー) がオーナーパートナーになります。
- 所有権は、ユーザーID > ライセンスID > サブスクリプションID > パートナーIDによって決まります。
- 各CDRには、1人のパートナーがアクセスできます。
- 通話記録の中には請求パートナーに紐付けられないものもあり、 組織に関連するすべてのパートナーがすべての記録に平等にアクセスできるわけではありません。 これらの記録には個人を特定できる情報(PII)が含まれている可能性があるためです。
ウェブフックコールバックURLをセットアップしてください
パートナーハブでWebhookを設定します。 パートナー組織ごとに設定できるWebhookは1つだけです。
「 組織のフル管理者レベルのアクセス権」を持つパートナーのフル管理者ロールがあり、Control Hub([ [パートナー] を選択)Webex CallingでCDR APIアクセスがオンになっていることを確認してください。
パートナー照合とレコード API を使用する場合も、同じアクセス要件が適用されます。
| 1 | |
| 2 |
] に移動します。
|
| 3 |
Webhookで使用するURLを入力してください。 URLは/webhookで終わる必要があります(たとえば、https://yourdomain.com/webhook)。
|
| 4 |
Webhookペイロードをシークレットトークンで認証したい場合は、 シークレットトークンを追加できます。 Webex Webhook とシークレットトークンの詳細については、「開発者向け Webex: Webhook」を参照してください。 |
| 5 |
Webhookに使用するリソースタイプを次の中から1つ選択してください。
|
パートナー API エンドポイント
Webhookに加えて、Webex Callingデータ調整をサポートするAPIエンドポイントを提供します。 これらのエンドポイントを使用すると、Webhookリスナーが受信していない可能性のある欠落しているレコードをデータストアに追いついたり、調整したりできます。 2つのAPIエンドポイントは、照合APIとレコードAPIです。
これらのAPIの記録は30日間利用可能です。 期待されるレコードをすべて確実に受け取れるように、レコード店を12時間ごとや24時間ごとなど、定期的に照合することをお勧めします。
これらのAPIにアクセスするには、パートナーアクセストークンを使用する必要があります。 認証するユーザーは、組織のフル管理者レベルのアクセス権を持つパートナーのフルアドミニストレーターで、Webex CallingCDR APIアクセスが有効になっている必要があります。 OAuthトークンにはスコープを含める必要があります。spark-admin:calling_cdr_read 読み取り専用の管理者ロールは、パートナー照合APIとレコードAPIには不十分です。
analytics-callingWebex Calling顧客組織のデータリージョンのエンドポイントを使用してください。 照合 API とレコード API の両方に該当するベース URL を使用してください。
- 米国とカナダ:
https://analytics-calling.webexapis.com - ヨーロッパ:
https://analytics-calling-eu.webexapis.com - インド:
https://analytics-calling-in.webexapis.com - オーストラリア:
https://analytics-calling-au.webexapis.com
サービスの負荷をより適切に処理するために、APIウィンドウ範囲は両方のエンドポイントに適用できます。
- 48時間を超える時間範囲の場合、許可される最大ウィンドウ期間は12時間です(強制されます)。
- パートナー組織IDの場合、APIは、トークンスコープごとに1分あたり1つの初期APIリクエストにレート制限されています。 ページ分割を使用する場合、1トークンあたり1分あたり最大10件のページ分割されたAPIリクエストを追加できます。これらは最初のリクエストの直後に行うことができます。
リコンシリエーション API エンドポイント
照合APIエンドポイントは、指定された期間内にパートナーが管理する各顧客について生成された通話記録の合計数を返します。 これらの合計を使用して、ローカルストレージを確認し、特定の顧客の通話記録の欠落や一貫性のない通話記録を特定できます。
アクセス要件:認証するユーザーは、完全な管理者レベルのアクセス権を持つパートナー管理者で、Webex CallingCDR APIアクセスが有効になっている必要があります。 spark-admin:calling_cdr_readアクセストークンにはスコープを含める必要があります。
200を超える顧客組織を管理している場合、APIは結果をページ分割して読みやすくします。
リコンシリエーション API エンドポイントのURLは次の形式を使用します。
https://analytics-calling.webexapis.com/v1/partners/cdrcountbyorg?endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z
API パラメーター
APIを使用して、過去30日間の通話記録を取得できます。 選択した時間枠は、現在のUTC時刻の少なくとも5分前に開始し、1回のAPI呼び出しの開始時刻と終了時刻の間が12時間を超えてはなりません。
APIパラメータは:
-
startTime(必須、文字列)—収集したい最初のレコードの開始日時(UTC)。 次のことを確認してください。
YYYY-MM-DDTHH:MM:SS.mmmZ時刻を次のようにフォーマットします。 例えば、2025-08-15T06:00:00.000Z。
- 開始日時は、現在のUTC時刻から30日以上経過してはいけません。
startTimeとの間隔は12時間を超えてはいけません。endTime
-
endTime(必須、文字列)—収集したいレコードの終了日時(UTC)。 記録は、通話が終了したレポート時間に基づいています。 次のことを確認してください。
YYYY-MM-DDTHH:MM:SS.mmmZ時刻を次のようにフォーマットします。 例えば、2025-08-15T18:00:00.000Z。- 終了日時は、現在のUTC時間の5分前で、30日以内である必要があります。
- 終了日時は、より大きくなければなりません
startTime。 startTimeとの間のウィンドウは12時間を超えてはいけません。endTime
リコンシリエーション API エンドポイントの JSON レスポンスの例:
{
"cdr_counts": [
{
"orgId": "zzzzzzzz-yyyy-zzzz-xxxx-yyyyyyyyyyyy",
"count": 3009
},
{
"orgId": "yyyyyyyy-yyyy-zzzz-xxxx-yyyyyyyyyyyy",
"count": 129
},
{
"orgId": "xxxxxxxx-yyyy-zzzz-xxxx-yyyyyyyyyyyy",
"count": 27895
}
]
}
API応答ヘッダーには、返された組織の総数と、追加のページがあるかどうかが示されます。 次のヘッダーパラメータをチェックして、すべてのページを検索したことを確認してください。
- ページ数:ページの総数 (たとえば、2)
- total-orgs: 回答に含まれていた組織の総数(たとえば、283)
- 現在のページ:現在のページ番号 (たとえば、1)
たとえば、ヘッダーに num-pages=2、total-orgs=283、現在のページ=1と表示されている場合、表示されているのは合計283の組織を含む2ページの回答の最初のページです。 次のページにアクセスするには、以下に示すように page=2 パラメーターを GET リクエストに追加します。
https://analytics-calling.webexapis.com/v1/partners/cdrcountbyorg?endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z&page=2
レコード API エンドポイント
Records APIエンドポイントは、照合APIを使用して不一致や欠落データが特定された特定の組織の欠落している通話記録を照会するために使用されます。
推奨フロー:/v1/partners/cdrcountbyorgまず電話してください。 そして、cdr_counts[].orgIdあなたが電話をかけたときには、orgId戻ってきたものとまったく同じものを使用してください/v1/partners/cdrsbyorg。
Records APIは、詳細通話履歴APIで説明されている形式と同じJSON形式で通話記録を返します。 返されたペイロードには、返された詳細な通話履歴ペイロードと同じフィールドが含まれています。 フィールドとその値の詳細については、Webex Calling詳細な通話履歴レポートを参照してください。
APIは、現在の時刻の5分前に終了した通話記録を提供します。 すべての通話記録を確実に入手できるようにするには、希望する時間帯の1時間後にAPIにクエリを実行することをお勧めします。
Records APIエンドポイントのURLは次の形式を使用しています。
https://analytics-calling.webexapis.com/v1/partners/cdrsbyorg?orgId=zzzzzzzz-yyyy-zzzz-xxxx-yyyyyyyyyyyy&endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z
API パラメーター
-
orgId(必須、文字列) — レコードを取得したい顧客組織のID。 パラメータ名は大文字と小文字が区別されます。 組織IDは、調整 APIのレスポンスフィールドから取得できます。cdr_counts[].orgId -
startTime(必須、文字列)—収集したい最初のレコードの開始日時(UTC)。 次のことを確認してください。
YYYY-MM-DDTHH:MM:SS.mmmZ時刻を次のようにフォーマットします。 例えば、2025-08-15T06:00:00.000Z。- 開始日時は、現在のUTC時刻から30日以上経過してはいけません。
startTime1回のAPIリクエストで、endTimeとの間隔が12時間を超えてはいけません。
-
endTime(必須、文字列)—収集したい最後のレコードの終了日時(UTC)。 記録は、通話が終了したレポート時間に基づいています。 次のことを確認してください。
YYYY-MM-DDTHH:MM:SS.mmmZ時刻を次のようにフォーマットします。 例えば、2025-08-15T18:00:00.000Z。- 終了日時は、現在のUTC時刻の少なくとも5分前で、30日以内である必要があります。
- 終了日時は、より大きくなければなりません
startTime。 startTime1回のAPIリクエストで、endTimeとの間隔が12時間を超えてはいけません。
-
max(オプション、数値)—応答の1ページあたりの最大レコード数を制限します。 次のことを確認してください。
- 範囲は500から5000です。 デフォルト値は5000です。 例えば、
max=1000。 - APIが返すレコードの数が指定された最大値を超える場合、応答はページ分割されます。
- 500未満の値を指定すると、500まで自動的に調整されます。 5000を超える値が指定された場合は、5000に調整されます。
- 範囲は500から5000です。 デフォルト値は5000です。 例えば、
ページネーション
APIレスポンスがページ分割されているかどうかを確認するには、レスポンスヘッダーにリンクヘッダーがあるかどうかを確認してください。 nextリンクヘッダーにリンクがある場合は、それを抽出し、startTimeForNextFetchその値を使用して次のレコードセットをリクエストしてください。 次のリンクがない場合は、選択した時間範囲のすべてのレポートが収集されます。
次のページのAPIリクエストはすぐに行うことができますが、トークンスコープあたり1分あたり最大10ページのリクエストにレート制限する必要があります。
レコードを取得するときは、ページ分割された回答や調整期間が繰り返される場合を含め、偶数処理と重複排除を使用してください。 reportId主キーとして使用し、最後に処理されたレコードを決定します。reportTime
たとえば、最初のAPIリクエストが次のような場合です。
https://analytics-calling.webexapis.com/v1/partners/cdrsbyorg?orgId=zzzzzzzz-yyyy-zzzz-xxxx-yyyyyyyyyyyy&endTime=2025-08-15T18:00:00.000Z&startTime=2025-08-15T06:00:00.000Z&max=5000
その場合、応答のリンクヘッダーは:
<https://analytics-calling.webexapis.com/v1/partners/cdrsbyorg?orgId=zzzzzzzz-yyyy-zzzz-xxxx-yyyyyyyyyyyy&endTime=2025-08-15T18:00:00.000Z&startTime=2025-08-15T06:00:00.000Z&startTimeForNextFetch=2025-08-15T09:30:00.000Z&totalCount=20000&max=5000>; rel="next"
rel="next"ページネーションはリンクヘッダーのみを使用します。 rel="next"応答にリンクが含まれている場合は、そのURLを使用して次のページのレコードを取得してください。 rel="next"応答にリンクが含まれていない場合は、選択した時間範囲で利用可能なすべてのレコードを取得したことになります。
このAPIのページ区切りはRFC5988(ウェブリンク)標準に準拠しています。 詳細については、「REST APIの基本」を参照してください。
APIエンドポイントの応答コードを理解してください
このセクションでは、Reconciliation APIエンドポイントとRecords APIエンドポイントを使用するときに発生する可能性のある一般的な応答コードの概要を説明します。 これらのエンドポイントは、 データの同期、検証、およびレポートにおいて重要な役割を果たします。 これらの応答コードを理解することは、 効果的なトラブルシューティングと、信頼性が高く安定した統合を維持するために不可欠です。
|
レスポンスコード |
レスポンスコードの説明 |
|---|---|
|
200 |
OK |
|
400 |
不正なリクエスト:リクエストは無効か、他の方法では対応できません。 添付のエラーメッセージで詳しく説明します。 |
|
401 |
無許可:認証情報がないか、正しくありません。 |
|
403 |
禁止:リクエストは理解されましたが、拒否されたか、アクセスが許可されていません。 |
|
404 |
見つかりません:要求されたURIが無効か、要求されたリソース(ユーザーなど)が存在しません。 また、要求された形式が要求された方法でサポートされていない場合にも返されます。 |
|
405 |
許可されていないメソッド:サポートされていないHTTPリクエストメソッドを使用してリソースに対してリクエストが行われました。 |
|
409 |
競合:システムの確立されたルールと矛盾するため、リクエストを処理できませんでした。 たとえば、ある人を同じ部屋に複数回追加することはできません。 |
|
410 |
なくなった:要求されたリソースはもう利用できません。 |
|
415 |
サポートされていないメディアタイプ:リクエストは、メディアタイプを指定せずにリソースに対して行われたか、サポートされていないメディアタイプを使用しました。 |
|
423 |
ロックされています:要求されたリソースは一時的に利用できません。 リクエストを再試行する前に何秒待つ必要があるかを指定するRetry-Afterヘッダーが表示される場合があります。 |
|
428 |
前提条件が必要です:ファイルはマルウェアをスキャンできないため、強制的にダウンロードする必要があります。 |
|
429 |
リクエストが多すぎます:一定時間に送信されたリクエストが多すぎて、リクエストのレートが制限されています。 リクエストが成功するまでに何秒待つ必要があるかを指定するRetry-Afterヘッダーが必要です。 |
|
451 |
デフォルトでは、 |
|
500 |
内部サーバーエラー:サーバーで問題が発生しました。 問題が解決しない場合は、[Webex デベロッパーサポートチーム] (/explore/support) までお気軽にお問い合わせください。 |
|
502 |
不正なゲートウェイ:サーバーは、リクエストの処理中に上流のサーバーから無効な応答を受け取りました。 後でもう一度やり直してください。 |
|
503 |
サービスは利用できません:サーバーはリクエストで過負荷になっています。 後でもう一度やり直してください。 |
|
504 |
ゲートウェイのタイムアウト:上流のサーバーが時間通りに応答しませんでした。 クエリで最大パラメータを使用している場合は、それを減らしてみてください。 |
パートナーレポート/テンプレート API
パートナーレポートAPIを使用して、パートナーハブで利用可能なレポートを生成してダウンロードできます。 詳細については、 パートナーレポート/テンプレートを参照してください。
パートナーは、Partner Hubから複数のレポートに直接アクセスしてダウンロードすることもできます。 詳細については、パートナーハブのレポートを参照してください。
改訂履歴
文書の改訂履歴
|
改訂日 |
記事に次の変更を加えました |
|---|---|
|
13/08/26 |
|
|
2/04/2026 |
|