В этой статье
Обзор
Настройка URL-адреса обратного вызова веб-перехватчика
dropdown icon
Конечные точки API партнеров
    Конечная точка API для сверки
    Конечная точка API записей
Понимание кодов ответов конечных точек API
Партнер reports/templates API
История изменений

Подробные записи звонков через веб-перехватчик для Webex Calling в Partner Hub

list-menuВ этой статье
list-menuОтправить обратную связь?

Партнеры Webex Calling, использующие многопользовательскую архитектуру (MT), могут настроить веб-перехватчик для сбора записей звонков Webex Calling для всех своих клиентов. Это позволяет эффективно сверять счета, проводить аналитику и составлять отчеты без необходимости запрашивать информацию у каждого клиента индивидуально.

Обзор

Веб-перехватчик «Подробные записи звонков» предлагает безопасное, масштабируемое и надежное решение, работающее на основе событий, а не запросов. Этот веб-перехватчик обеспечивает более полную информацию о действиях ваших клиентов в Webex Calling, поддерживая различные сценарии использования, от выставления счетов до создания индивидуальных отчетов.

С помощью этого веб-перехватчика вы можете удобно собирать данные обо всех клиентах, управляемых через Partner Hub, без необходимости запрашивать информацию о каждом клиенте по отдельности. Этот веб-хук позволяет разрабатывать пользовательские приложения для отчетности, выставления счетов и аналитики как для внутренних бизнес-задач, так и для дополнительных услуг.

Для ознакомления с веб-хуком и сопутствующими API посмотрите этот видеоподкаст: API подробной истории звонков партнеров Webex.

Что предоставляет веб-хук для партнеров

Веб-хук передает подробные записи истории звонков каждые 5 минут. Каждый полезный груз веб-перехватчика содержит:

  • Записи звонков, завершившихся за 10–5 минут до текущего времени.
  • Все просроченные записи обрабатываются облачной системой Webex Calling.
  • Автоматически заполняет несвоевременно обрабатываемые записи о звонках в последующих полезных нагрузках веб-хуков для обеспечения надежной доставки.

Чтобы показать, как записи звонков включаются в каждый пакет данных, рассмотрим следующий пример:

  • Полезная нагрузка получена в 14:05 содержит звонки, которые завершились между 13:55 и 14:00.
  • Звонки, завершающиеся между 14:00 и 14:05 включены в 14:10 полезная нагрузка.
  • Записи, завершенные ранее (например, звонок, который закончился в 14:04) но обрабатывается с задержкой облачной службой Webex Calling (например, в 14:11) включены в следующую запланированную полезную нагрузку (например, 14:15).

Веб-хуки надежно передают записи. Однако при определенных условиях, когда система воспроизводит записи повторно, в последующих полезных нагрузках веб-перехватчика могут появляться дублирующиеся записи. Вы несёте ответственность за удаление дубликатов записей. Для выявления дублирующихся записей используйте поле reportId в качестве первичного ключа и поле reportTime для определения момента завершения или обработки звонка. Используйте эти поля для обновления или вставки записей во внутренние хранилища данных.

Веб-перехватчик в партнерском хабе

Предоставив веб-хук, вы позволяете аналитической платформе отправлять записи звонков на ваш URL-адрес обратного вызова всякий раз, когда они генерируются.

Записи звонков Webex передаются в том же формате, что и существующие API подробных записей звонков. Вы можете настроить веб-хук и выбрать один из двух типов ленты:

  • Аналитика — включает все записи звонков для всех клиентских организаций, с которыми партнер имеет партнерские отношения в рамках Webex Calling. Это включает организации, в которых:
    • Партнер управляет организацией клиента, выполняя роль полноправного администратора партнера.
    • У организации-заказчика имеется активная подписка на Webex Calling в рамках организации-партнера.
  • Выставление счетов — включает записи звонков, совершенных пользователями, имеющими лицензию Webex Calling, приобретенную и предоставленную партнером. В этот канал включены записи звонков для рабочих пространств.

Доступ и конфиденциальность данных

Доступ к записям о деталях звонков (CDR) для выставления счетов имеет только партнер-владелец.

  • Партнер (или субпартнер), управляющий лицензией, связанной с записью звонка, становится партнером-владельцем.
  • Право собственности определяется следующим образом: ID пользователя > Идентификатор лицензии > Идентификатор подписки > Идентификатор партнера.
  • Доступ к каждому окну CDR имеет только один партнер.
  • Некоторые записи звонков не привязаны к конкретному биллинговому партнеру, и не все партнеры, связанные с организацией, имеют равный доступ ко всем записям, поскольку эти записи могут содержать персональные данные.

Настройка URL-адреса обратного вызова веб-перехватчика

Настройте веб-перехватчик в Партнерском центре. На каждую партнерскую организацию можно настроить только один веб-перехватчик.

Убедитесь, что у вас есть роль «Партнер» с полным доступом администратора «Уровень доступа администратора организации», а также Доступ к API Webex Calling CDR отмечен в Центре управления (в разделе Управление > Пользователи, выберите администратора с полным правами или партнера с полным правами, а затем выберите Роли администратора > Партнер).

Скриншот, демонстрирующий настройки ролей администратора с выбранными ролями «Администратор партнера» и «Полный администратор партнера», а также с отмеченным пунктом «Доступ к API Webex Calling CDR» в разделе «Функциональные настройки».

1

Войдите в Partner Hub.

2

Перейти в Настройки организации > Детали вызова.

Скриншот настроек организации для записей сведений о звонках, отображающий поля для URL-адреса веб-перехватчика, секретного токена и типа ресурса с выбранной функцией аналитики.
3

Введите URL-адрес для использования в Webhook.

URL-адрес должен заканчиваться на /webhook (например, https://yourdomain.com/webhook).
4

Если вы хотите аутентифицировать данные веб-перехватчика с помощью секретного токена, вы можете его добавить. Для получения дополнительной информации о веб-перехватчиках Webex и секретных токенах см. Webex для разработчиков: Вебхуки.

5

Выберите один из следующих типов ресурсовдля использования в качестве веб-перехватчика:

  • Аналитика— Включает все записи звонков для всех клиентских организаций, с которыми партнер имеет отношения в рамках Webex Calling.
  • Выставление счетов— Включает записи звонков для пользователей, которым партнер продал лицензии Webex Calling. В этот канал включены записи звонков для рабочих пространств.

Конечные точки API партнеров

Помимо веб-хука, Webex Calling предоставляет API-интерфейсы для поддержки сверки данных. Эти конечные точки позволяют вам восстановить или согласовать ваши хранилища данных с любыми недостающими записями, которые ваш обработчик веб-перехватчиков мог не получить. Два API-интерфейса — это API сверки и API записей.

Данные, полученные через эти API, доступны в течение 30 дней. Чтобы гарантировать получение всех ожидаемых записей, мы рекомендуем периодически, например, каждые 12 или 24 часа, сверять ваши хранилища записей.

Для доступа к этим API необходимо использовать партнерский токен доступа. Получайте и управляйте своим партнерским токеном доступа в соответствии со стандартными методами управления токенами доступа разработчиков Webex.

Диапазоны значений API-интерфейса применяются к обеим конечным точкам для более эффективного управления нагрузкой на сервис.

  • Для временных интервалов более 48 часов максимально допустимая продолжительность окна составляет 12 часов (рекомендуется и соблюдается).
  • Для временных интервалов в 48 часов или менее максимально допустимая продолжительность окна составляет 48 часов (не рекомендуется; эта опция будет упразднена с 30 января 2026 года).
  • Для идентификатора партнерской организации использование API ограничено одним первоначальным запросом в минуту на каждый токен. При использовании пагинации допускается до 10 дополнительных запросов к API с пагинацией в минуту на каждый токен, и эти запросы могут быть выполнены сразу после первоначального запроса.

Конечная точка API для сверки

Конечная точка API сверки возвращает общее количество записей о звонках, сгенерированных для каждого клиента, обслуживаемого партнером, за указанный период времени. Эти итоговые данные можно использовать для проверки локального хранилища и выявления любых отсутствующих или несоответствующих записей о звонках для конкретных клиентов.

Если вы управляете более чем 200 клиентскими организациями, API будет разбивать результаты на страницы для повышения читаемости.

URL-адрес конечной точки API сверки использует следующий формат:

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 дней. Выбранный вами временной интервал должен начинаться как минимум за 5 минут до текущего времени UTC и не может превышать 12 часов между временем начала и окончания в рамках одного вызова API.

Параметры API:

  • startTime (обязательно, строка) — Дата и время начала сбора первой записи (UTC). Убедитесь, что:
    • Время форматируется в виде YYYY-MM-DDTHH:MM:SS.mmmZквадратных скобок . Например, 2025-08-15T06:00:00.000Z.
    • Дата и время начала не должны быть старше 30 дней с текущего времени UTC.
    • Интервал между startTime и endTime не может превышать 12 часов.
  • endTime (обязательно, строка) — Дата и время окончания (UTC) для записей, которые вы хотите собрать. Записи ведутся по времени составления отчета, то есть по моменту завершения звонка. Убедитесь, что:
    • Время форматируется в виде YYYY-MM-DDTHH:MM:SS.mmmZквадратных скобок . Например, 2025-08-15T18:00:00.000Z.
    • Дата и время окончания должны быть на 5 минут раньше текущего времени UTC и не старше 30 дней.
    • Дата и время окончания должны быть больше, чем startTime.
    • Интервал между символами startTime и endTime не может превышать 12 часов.

Пример JSON-ответа от конечной точки API сверки:


          {
          "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 указывают общее количество возвращенных организаций и наличие дополнительных страниц. Проверьте следующие параметры заголовка, чтобы убедиться, что вы выполнили запрос ко всем страницам:

  • num-pages: Общее количество страниц (например, 2)
  • total-orgs: Общее количество организаций, включенных в ответ (например, 283)
  • текущая страница: Текущий номер страницы (например, 1)

Например, если в заголовках отображается num-pages=2, total-orgs=283, и current-page=1, Вы просматриваете первую страницу двухстраничного ответа, содержащего информацию о 283 организациях. Чтобы перейти на следующую страницу, добавьте 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 записей возвращает записи звонков в формате JSON, идентичном формату, описанному в API подробной истории звонков. Возвращаемые данные содержат идентичные поля с данными из раздела «Подробная история звонков». Для получения дополнительной информации о полях и их значениях см. Подробный отчет об истории звонков Webex.

API предоставляет записи звонков, завершившихся за 5 минут до текущего времени. Чтобы гарантировать доступность всех записей звонков, мы рекомендуем отправлять запрос к API через час после выбранного вами временного интервала.

URL-адрес конечной точки API записей использует следующий формат:

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 (обязательно, строка) — Идентификатор организации, для которой вы хотите получить записи. Идентификаторы организаций можно получить через API сверки.
  • startTime (обязательно, строка) — Дата и время начала сбора первой записи (UTC). Убедитесь, что:
    • Время форматируется в виде YYYY-MM-DDTHH:MM:SS.mmmZквадратных скобок . Например, 2025-08-15T06:00:00.000Z.
    • Дата и время начала не должны быть старше 30 дней с текущего времени UTC.
    • Интервал между символами startTime и endTime не должен превышать 12 часов в одном API-запросе.
  • endTime (обязательно, строка) — Дата и время окончания (UTC) последней записи, которую вы хотите собрать. Записи ведутся по времени составления отчета, то есть по моменту завершения звонка. Убедитесь, что:
    • Время форматируется в виде YYYY-MM-DDTHH:MM:SS.mmmZквадратных скобок . Например, 2025-08-15T18:00:00.000Z.
    • Дата и время окончания должны быть как минимум на 5 минут раньше текущего времени UTC и не старше 30 дней.
    • Дата и время окончания должны быть больше, чем startTime.
    • Интервал между символами startTime и endTime не должен превышать 12 часов в одном API-запросе.
  • Макс. (необязательно, число) — ограничивает максимальное количество записей на странице в ответе. Убедитесь, что:
    • Диапазон значений составляет от 500 до 5000. Значение по умолчанию — 5000. Например, Max=1000.
    • Если API возвращает больше записей, чем указано в значении Max, то ответ разбивается на страницы.
    • Если указано значение ниже 500, оно автоматически увеличивается до 500. Если указано значение выше 5000, оно уменьшается до 5000.

Разбивка на страницы

Чтобы определить, осуществляется ли постраничная обработка ответов API, проверьте заголовки ответа на наличие заголовка Link. Если в заголовке Link присутствует ссылка next, извлеките её и используйте значение startTimeForNextFetch для запроса следующего набора записей. Если следующая ссылка отсутствует, то собираются все отчеты за выбранный временной диапазон.

Запросы к API для перехода на последующие страницы могут выполняться немедленно, но их частота должна быть ограничена максимум 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 (веб-ссылки). Для получения дополнительной информации см. Основы REST API.

Понимание кодов ответов конечных точек API

В этом разделе представлен обзор распространенных кодов ответов, которые могут встречаться при работе с конечной точкой API сверки и конечной точкой API записей . Эти конечные точки играют решающую роль в синхронизации, проверке и формировании отчетов по данным. Понимание этих кодов ответов имеет важное значение для эффективного устранения неполадок и поддержания надежной и стабильной интеграции.

Таблица 1. коды ответов конечной точки API

Код ответа

Описание кода ответа

200

ОК

400

Неудачный запрос. Запрос недействителен или не может быть выполнен иным образом. Сопутствующее сообщение об ошибке даст более подробное объяснение.

401

Несанкционированный: Учетные данные для аутентификации отсутствовали или были неверны.

403

Запрещенный: Запрос понят, но в его удовлетворении отказано или доступ запрещен.

404

Не найдено: Запрошенный URI недействителен, или запрошенный ресурс, например пользователь, не существует. Также возвращается в случае, если запрошенный формат не поддерживается запрошенным методом.

405

Метод не разрешен: Запрос к ресурсу был отправлен с использованием метода HTTP-запроса, который не поддерживается.

409

Конфликт: Запрос не может быть обработан, поскольку он противоречит одному из установленных правил системы. Например, одного и того же человека нельзя добавлять в комнату более одного раза.

410

Ушел: Запрошенный ресурс больше недоступен.

415

Неподдерживаемый тип носителя: Запрос был отправлен к ресурсу без указания типа носителя или с использованием неподдерживаемого типа носителя.

423

Заблокировано: Запрошенный ресурс временно недоступен. В заголовке Retry-After может присутствовать указание на то, сколько секунд необходимо подождать перед повторной попыткой выполнения запроса.

428

Требуемое предварительное условие: Файлы не могут быть проверены на наличие вредоносных программ и требуют принудительной загрузки.

429

Слишком много запросов: За определенный промежуток времени было отправлено слишком много запросов, и количество запросов было ограничено. В заголовке Retry-After должно быть указано, сколько секунд необходимо подождать до успешного выполнения запроса.

500

Внутренняя ошибка сервера: На сервере произошла ошибка. Если проблема не исчезнет, пожалуйста, свяжитесь с нами. [Webex Поддержка разработчиков team](/explore/support).

502

Плохой шлюз: При обработке запроса сервер получил недействительный ответ от вышестоящего сервера. Повторите попытку позже.

503

Сервис недоступен: Сервер перегружен запросами. Повторите попытку позже.

504

Таймаут шлюза: Вышестоящий сервер не ответил вовремя. Если в вашем запросе используется параметр max, попробуйте его уменьшить.

Партнер reports/templates API

Вы можете создавать и загружать отчеты, доступные в Partner Hub, используя API Partner Reports . Для получения дополнительной информации см. партнера . report/templates.

Партнеры также могут получать доступ к различным отчетам и загружать их непосредственно из Partner Hub. Для получения дополнительной информации см. Отчеты Partner Hub.

История изменений

История изменений документа

Дата пересмотра

Мы внесли в статью следующие изменения.

1/14/2026

  • Создана таблица истории изменений, отслеживающая все изменения, внесенные с течением времени.

  • Внесены изменения в разделы «Конечные точки API сверки» и «Конечные точки API записей» для добавления таблицы значений кодов ошибок.

Была ли статья полезной?
Была ли статья полезной?