この記事の内容
概要
Webhook コールバック URL を設定する
dropdown icon
パートナーAPIエンドポイント
    調整APIエンドポイント
    レコードAPIエンドポイント
    パートナー reports/templates API

パートナー ハブの Webex Calling の詳細な通話記録 Webhook

list-menuこの記事の内容
list-menuフィードバックがある場合

Webex Calling マルチテナント (MT) パートナーは、Webhook を設定してすべての顧客の Webex Calling レコードを収集できます。これにより、各顧客に個別に問い合わせる必要がなくなり、効率的な請求調整、分析、 、レポート作成が可能になります。

概要

詳細な通話記録 Webhook は、リクエストではなくイベントによって駆動される、安全でスケーラブルかつ堅牢なソリューションを提供します。この Webhook により、顧客の Webex Calling アクティビティの可視性が向上し、課金からカスタマイズされたレポートまでのユースケースがサポートされます。

この Webhook を使用すると、各顧客に個別に問い合わせることなく、Partner Hub を通じて管理されるすべての顧客のレコードを簡単に収集できます。この Webhook を使用すると、社内のビジネス要件と付加価値サービスの両方に対応するカスタム レポート、課金、分析アプリケーションを開発できます。

Webhook とそれに付随する API の紹介については、この Vidcast をご覧ください。Webex 通話パートナーの詳細な通話履歴 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 はレコードを確実に配信します。ただし、システムが特定の条件下でレコードを再生すると、後続の Webhook ペイロードで重複したレコードが受信される場合があります。レコードの重複排除を処理するのはあなたの責任です。重複レコードを識別するには、 reportId フィールドを主キーとして使用し、 reportTime フィールドを使用して通話が完了または処理されたタイミングを判断します。これらのフィールドを使用して、内部データ ストアのレコードを更新または挿入します。

Parter HubのWebhook

Webhook を提供することで、分析プラットフォームは通話記録が生成されるたびにコールバック URL に送信できるようになります。

Webex Calling の記録は、既存の 詳細通話記録 APIと同じ形式を使用して配信されます。Webhook を設定し、次の 2 種類のフィードから選択できます。

  • 分析 - パートナーが Webex Calling 関係を持つすべての顧客組織のすべての通話記録が含まれます。これには次のような組織が含まれます。
    • パートナーは、パートナー フル管理者のロールを使用して顧客組織を管理します。
    • 顧客組織には、パートナー組織内でアクティブな Webex Calling サブスクリプションがあります。
  • 請求 - パートナーが販売およびプロビジョニングした Webex Calling ライセンスを持つユーザーによる通話の通話記録が含まれます。このフィードには、ワークスペースの通話記録が含まれます。

アクセスとデータのプライバシー

請求のための通話詳細記録 (CDR) にアクセスできるのは、所有パートナーのみです。

  • 通話記録に関連付けられたライセンスを管理するパートナー (またはサブパートナー) が所有パートナーになります。
  • 所有権は以下によって決定されます: ユーザーID > ライセンスID > サブスクリプションID > パートナーID。
  • 各 CDR には 1 人のパートナーがアクセスできます。
  • 一部の通話記録は請求パートナーにマッピングされません。また、これらの記録には個人を特定できる情報 (PII) が含まれている可能性があるため、組織に関連付けられたすべてのパートナーがすべての記録に平等にアクセスできるわけではありません。

Webhook コールバック URL を設定する

パートナー ハブで Webhook を構成します。パートナー組織ごとに設定できる Webhook は 1 つだけです。

「組織のフル管理者レベルのアクセス」を持つパートナーフル管理者ロールがあり、 Webex Calling CDR API アクセス がコントロール ハブ( 管理 の下)でチェックされていることを確認します。 > ユーザー、フル管理者またはパートナーフル管理者を選択し、 管理者ロール を選択します。 > パートナー)。

パートナー管理者とパートナーフル管理者が選択され、機能設定で Webex Calling CDR API アクセスがチェックされた管理者ロール設定を示すスクリーンショット。

1

Partner Hub にサインインします。

2

組織設定 に移動 > 通話詳細記録

通話詳細レコードの組織設定のスクリーンショット。分析が選択された状態で、Webhook URL、シークレット トークン、リソース タイプのフィールドが表示されています。
3

Webhookの下に使用する URL を入力します。

URLは以下で終わる必要があります /webhook (例えば、 https://yourdomain.com/webhook).
4

シークレット トークンを使用して Webhook ペイロードを認証する場合は、シークレット トークンを追加できます。Webex ウェブフックとシークレット トークンの詳細については、 Webex for Developers を参照してください。Webhooks

5

Webhook に使用する次の リソース タイプ のいずれかを選択します。

  • 分析—パートナーが Webex Calling 関係を持つすべての顧客組織のすべての通話記録が含まれます。
  • 請求—パートナーが Webex Calling ライセンスを販売したユーザーの通話記録が含まれます。このフィードには、ワークスペースの通話記録が含まれます。

パートナーAPIエンドポイント

Webhook に加えて、Webex Calling はデータ調整をサポートする API エンドポイントを提供します。これらのエンドポイントを使用すると、Webhook リスナーが受信していない可能性のある不足レコードをデータ ストアに追いついたり調整したりできます。2 つの API エンドポイントは、 調整 APIレコード APIです。

これらの API からの記録は 30 日間利用できます。必要なレコードをすべて確実に受け取るには、12 時間ごとまたは 24 時間ごとなど、定期的にレコード ストアを調整することをお勧めします。

これらの API にアクセスするには、パートナー アクセス トークンを使用する必要があります。標準の Webex Developer アクセス トークン管理プラクティスに従って、パートナー アクセス トークンを取得および管理します。

API ウィンドウ範囲は、サービス負荷をより適切に処理するために両方のエンドポイントに適用できます。

  • 48 時間を超える時間範囲の場合、許容されるウィンドウの最大期間は 12 時間です (推奨および強制)。
  • 48 時間以下の時間範囲の場合、許容されるウィンドウの最大期間は 48 時間です (推奨されません。このオプションは 2026 年 1 月 30 日をもって廃止されます)。
  • パートナー組織 ID の場合、API はトークン スコープごとに 1 分あたり 1 回の初期 API リクエストにレート制限されます。ページネーションを使用する場合、1 分あたり、トークンごとに最大 10 件の追加のページネーション API リクエストが許可され、これらは最初のリクエストの直後に行うことができます。

調整APIエンドポイント

調整 API エンドポイントは、指定された期間内にパートナーが管理する各顧客に対して生成された通話記録の合計数を返します。これらの合計を使用して、ローカル ストレージを確認し、特定の顧客の欠落した通話記録や矛盾した通話記録を特定できます。

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 日以内である必要があります。
    • startTimeendTime の間のウィンドウは 12 時間を超えることはできません。
  • endTime (必須、文字列) - 収集するレコードの終了日時 (UTC)。記録は、通話が完了したときのレポート時間に基づいています。次のことを確認してください。
    • 時間を YYYY-MM-DDTHH:MM:SS.mmmZとしてフォーマットします。例えば、 2025-08-15T18:00:00.000Z
    • 終了日時は、現在の UTC 時間の 5 分前で、30 日以内である必要があります。
    • 終了日時は startTimeより大きくなければなりません。
    • startTimeendTime の間のウィンドウは 12 時間を超えることはできません。

調整 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)
  • 合計組織数: 回答に含まれる組織の総数(例:283)
  • 現在のページ: 現在のページ番号(例:1)

例えば、ヘッダーに num-pages=2, total-orgs=283, そして current-page=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エンドポイント

レコード API エンドポイントは、調整 API を使用して不一致または欠落データが特定された特定の組織の欠落した通話記録を照会するために使用されます。

レコード 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 は、Reconciliation API から取得できます。
  • startTime (必須、文字列) - 収集する最初のレコードの開始日時 (UTC)。次のことを確認してください。
    • 時間を YYYY-MM-DDTHH:MM:SS.mmmZとしてフォーマットします。例えば、 2025-08-15T06:00:00.000Z
    • 開始日時は、現在の UTC 時間から 30 日以内である必要があります。
    • 1 回の API リクエストにおける startTimeendTime の間隔は 12 時間を超えてはなりません。
  • endTime (必須、文字列) - 収集する最後のレコードの終了日時 (UTC)。記録は、通話が完了したときのレポート時間に基づいています。次のことを確認してください。
    • 時間を YYYY-MM-DDTHH:MM:SS.mmmZとしてフォーマットします。例えば、 2025-08-15T18:00:00.000Z
    • 終了日時は、現在の UTC 時間より少なくとも 5 分前、かつ 30 日以内である必要があります。
    • 終了日時は startTimeより大きくなければなりません。
    • 1 回の API リクエストにおける startTimeendTime の間隔は 12 時間を超えてはなりません。
  • Max (オプション、数値) - 応答のページあたりのレコードの最大数を制限します。次のことを確認してください。
    • 範囲は500~5000です。デフォルト値は 5000 です。例えば、 Max=1000
    • API が返すレコードの数が指定された最大値よりも多い場合、応答はページ分割されます。
    • 500未満の値を指定した場合、自動的に500まで調整されます。5000 を超える値を指定した場合、5000 に調整されます。

ページネーション

API レスポンスがページ分割されているかどうかを確認するには、レスポンス ヘッダーで Link ヘッダーを確認します。Link ヘッダーに next リンクが存在する場合は、それを抽出し、 startTimeForNextFetch 値を使用して次のレコード セットを要求します。次のリンクがない場合は、選択した時間範囲のすべてのレポートが収集されます。

後続のページに対する API リクエストはすぐに実行できますが、トークン スコープごとに 1 分あたり最大 10 ページ分割リクエストにレート制限する必要があります。

たとえば、最初の 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

応答の Link ヘッダーは次のようになります。

; rel="next"

その他の可能なリンク値には、それぞれ最初のページと前のページを表す rel="first"rel="prev" が含まれます。

この API のページ区切りは、RFC5988 (Web リンク) 標準に従います。詳細については、 REST API の基礎を参照してください。

パートナー reports/templates API

パートナー レポート APIを使用して、パートナー ハブで利用可能なレポートを生成およびダウンロードできます。詳細については、 パートナーをご覧ください report/templates.

パートナーは、パートナー ハブから直接複数のレポートにアクセスしてダウンロードすることもできます。詳細については、 パートナー ハブ レポートを参照してください。

この投稿記事は役に立ちましたか?
この投稿記事は役に立ちましたか?