Neste artigo
Visão geral
Configurar um URL de retorno de chamada do webhook
dropdown icon
Endpoints da API do parceiro
    Endpoint da API de reconciliação
    Endpoint da API de registros
Entenda os códigos de resposta do endpoint da API
API de relatórios/modelos de parceiros
Histórico de revisões
Webhook detalhado de registros de chamadas para Webex Calling no Partner Hub
list-menuNeste artigo
list-menuComentários?

Os parceiros multilocatários (MT) Webex Calling podem configurar um webhook para reunir registros Webex Calling para todos os seus clientes. Isso permite uma reconciliação eficiente de faturamento, análises e relatórios sem a necessidade de consultar cada cliente individualmente.

Visão geral

O webhook Detailed Call Records oferece uma solução segura, escalável e robusta, orientada por eventos em vez de solicitações. Esse webhook oferece maior visibilidade das Webex Calling atividades de seus clientes, dando suporte a casos de uso, desde cobrança até relatórios personalizados.

Você pode usar esse webhook para reunir registros convenientemente de todos os clientes gerenciados pelo Partner Hub sem consultar cada cliente individualmente. Esse webhook permite que você desenvolva aplicativos personalizados de relatórios, faturamento e análise para requisitos comerciais internos e serviços de valor agregado.

Para uma introdução ao webhook e às APIs que o acompanham, assista a esta API Vidcast: Webex Calling Partner Detailed Call History.

O que o webhook do Partner oferece

O webhook fornece registros detalhados do histórico de chamadas a cada 5 minutos. Cada carga útil do webhook contém :

  • Registros de chamadas que terminaram entre 10 minutos e 5 minutos antes da hora atual.
  • Qualquer registro atrasado processado pela Webex Calling nuvem.
  • Preenche automaticamente os registros de chamadas atrasadas nas cargas úteis subsequentes do webhook para garantir uma entrega confiável.

Para mostrar como os registros de chamadas são incluídos em cada carga, considere o exemplo a seguir:

  • Uma carga recebida às 14:05 contém chamadas que terminaram entre 13:55 e 14:00.
  • As chamadas que terminam entre 14:00 e 14:05 estão incluídas na carga útil 14:10.
  • Os registros concluídos anteriormente (por exemplo, uma chamada que terminou às 14:04), mas processados com atraso pela Webex Calling nuvem (por exemplo, às 14:11), são incluídos na próxima carga programada (por exemplo, 14:15).

Os webhooks entregam registros de forma confiável. No entanto, você pode receber registros duplicados em cargas úteis de webhook subsequentes quando o sistema reproduz registros sob certas condições. Você é responsável por lidar com a desduplicação de registros. Para identificar registros duplicados, use o campo ReportID como chave primária e o campo ReportTime para determinar quando uma chamada foi concluída ou processada. Use esses campos para atualizar ou inserir os registros em seus armazenamentos de dados internos.

Webhook no Partner Hub

Ao fornecer um webhook, você permite que a plataforma de análise envie registros de chamadas para sua URL de retorno de chamada sempre que eles forem gerados.

Webex Callingos registros são entregues usando o mesmo formato das APIs de registros detalhados de chamadas existentes. Você pode configurar um webhook e escolher entre dois tipos de feed:

  • Análise — Inclui todos os registros de chamadas de todas as organizações de clientes com as quais o parceiro tem um Webex Calling relacionamento. Isso inclui organizações em que:
    • O parceiro gerencia a organização do cliente com a função de administrador completo do parceiro.
    • A organização do cliente tem uma Webex Calling assinatura ativa dentro da organização parceira.
  • Faturamento — Inclui registros de chamadas feitas por usuários com uma Webex Calling licença vendida e provisionada pelo parceiro. Os registros de chamadas para espaços de trabalho estão incluídos neste feed.

Acesso e privacidade de dados

Somente o parceiro proprietário pode acessar os registros de detalhes de chamadas (CDR) para cobrança.

  • Um parceiro (ou subparceiro) que gerencia a licença associada ao registro da chamada se torna o parceiro proprietário.
  • A propriedade é determinada por: ID do usuário > ID da licença > ID da assinatura > ID do parceiro.
  • Cada CDR é acessível a um único parceiro.
  • Alguns registros de chamadas não são mapeados para um parceiro de cobrança, e nem todos os parceiros associados a uma organização recebem acesso igual a todos os registros, pois esses registros podem conter informações de identificação pessoal (PII).

Configurar um URL de retorno de chamada do webhook

Configure o webhook no Partner Hub. Você só pode configurar um webhook por organização parceira.

Certifique-se de ter a função de administrador completo do Parceiro com “ Acesso organizacional completo em nível administrativo” e o acesso à API Webex Calling CDR verificado no Control Hub (em Gerenciamento > Usuários, selecione um administrador completo ou administrador completo do parceiro e, em seguida, selecione Funções de administrador > Parceiro).

Os mesmos requisitos de acesso se aplicam quando você usa as APIs de Reconciliação e Registros de Parceiros.

Screenshot showing administrator roles settings with Partner admin and Partner full admin selected, along with Webex Calling CDR API Access checked under Functional settings.

1

Faça login no Partner Hub.

2

Vá para Configurações da organização > Registros de detalhes da chamada.

Screenshot of Organization Settings for Call Detail Records, displaying fields for Webhook URL, Secret token, and Resource Type with Analytics selected.
3

Insira um URL para usar em Webhook.

O URL deve terminar com /webhook (por exemplo, https://yourdomain.com/webhook).
4

Se quiser autenticar suas cargas de webhook com um token secreto, você pode adicionar um. Para obter mais informações sobre webhooks e tokens secretos Webex, consulte Webex para desenvolvedores: Webhooks.

5

Selecione um dos seguintes tipos de recurso para usar no webhook:

  • Análise — inclui todos os registros de chamadas de todas as organizações de clientes com as quais o parceiro tem um Webex Calling relacionamento.
  • Faturamento — inclui registros de chamadas para usuários aos quais o parceiro vendeu Webex Calling licenças. Os registros de chamadas para espaços de trabalho estão incluídos neste feed.

Endpoints da API do parceiro

Além do webhook, Webex Calling fornece endpoints de API para oferecer suporte à reconciliação de dados. Esses endpoints permitem que você atualize ou reconcilie seus armazenamentos de dados com quaisquer registros ausentes que seu ouvinte de webhook possa não ter recebido. Os dois endpoints da API são a API de reconciliação e a API de registros.

Os registros dessas APIs estão disponíveis por 30 dias. Para garantir que você receba todos os registros esperados, recomendamos reconciliar suas lojas de discos periodicamente, como a cada 12 ou 24 horas.

Você deve usar um token de acesso de parceiro para acessar essas APIs. O usuário autenticador deve ser um administrador completo do parceiro com acesso organizacional completo no nível administrativo e deve ter o acesso à API Webex Calling CDR ativado. O token OAuth deve incluir o spark-admin:calling_cdr_readescopo. As funções de administrador somente de leitura não são suficientes para as APIs de Reconciliação e Registros de Parceiros.

Use o analytics-callingendpoint para a região de Webex Calling dados da organização do cliente. Use o URL base aplicável para as APIs de Reconciliação e Registros:

  • EUA e Canadá: https://analytics-calling.webexapis.com
  • Europa: https://analytics-calling-eu.webexapis.com
  • Índia: https://analytics-calling-in.webexapis.com
  • Austrália: https://analytics-calling-au.webexapis.com

Os intervalos de janelas da API são aplicáveis a ambos os endpoints para lidar melhor com a carga de serviço.

  • Para intervalos de tempo superiores a 48 horas, a duração máxima permitida da janela é de 12 horas (obrigatória).
  • Para um ID de organização parceira, as APIs são limitadas a uma solicitação inicial de API por minuto, por escopo de token. Se a paginação for usada, até 10 solicitações adicionais de API paginadas por minuto, por token, serão permitidas, e elas poderão ser feitas imediatamente após a solicitação inicial.

Endpoint da API de reconciliação

O endpoint da API de reconciliação retorna o número total de registros de chamadas gerados para cada cliente gerenciado pelo parceiro dentro do período de tempo especificado. Você pode usar esses totais para verificar seu armazenamento local e identificar quaisquer registros de chamadas ausentes ou inconsistentes para clientes específicos.

Requisito de acesso: O usuário autenticador deve ser um administrador parceiro com acesso total em nível de administrador e deve ter o acesso à API Webex Calling CDR ativado. O token de acesso deve incluir o spark-admin:calling_cdr_readescopo.

Se você gerencia mais de 200 organizações de clientes, a API pagina os resultados para melhorar a legibilidade.

O URL do endpoint da API de reconciliação usa o seguinte formato:

https://analytics-calling.webexapis.com/v1/partners/cdrcountbyorg?endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z

Parâmetros da API

Você pode usar a API para recuperar registros de chamadas dos últimos 30 dias. A janela de tempo selecionada deve começar pelo menos 5 minutos antes do horário UTC atual e não pode exceder 12 horas entre os horários de início e término em uma única chamada de API.

Os parâmetros da API são:

  • StartTime (obrigatório, string) — A data e a hora de início (UTC) do primeiro registro que você deseja coletar. Assegure-se de que:
    • Você formata a hora como YYYY-MM-DDTHH:MM:SS.mmmZ. Por exemplo, 2025-08-15T06:00:00.000Z.
    • A data e a hora de início não devem ter mais de 30 dias a partir do horário UTC atual.
    • A janela entre startTimee não endTimepode exceder 12 horas.
  • endTime (required, string) — A data e a hora de término (UTC) dos registros que você deseja coletar. Os registros são baseados na hora do relatório, que é quando a chamada é concluída. Assegure-se de que:
    • Você formata a hora como YYYY-MM-DDTHH:MM:SS.mmmZ. Por exemplo, 2025-08-15T18:00:00.000Z.
    • A data e a hora de término devem ser 5 minutos antes da hora UTC atual e não devem ter mais de 30 dias.
    • A data e a hora de término devem ser maiores que startTimeo.
    • A janela entre startTimee não endTimepode exceder 12 horas.

Exemplo de uma resposta JSON do endpoint da API de reconciliação:


          {
          "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
          }
          ]
          }          
        

Os cabeçalhos de resposta da API indicam o número total de organizações retornadas e se páginas adicionais estão disponíveis. Verifique os seguintes parâmetros de cabeçalho para garantir que você tenha consultado todas as páginas:

  • num-pages: número total de páginas (por exemplo, 2)
  • total-orgs: número total de organizações incluídas na resposta (por exemplo, 283)
  • página atual: o número da página atual (por exemplo, 1)

Por exemplo, se os cabeçalhos mostrarem num-pages=2, total-orgs=283 e current-page=1, você está visualizando a primeira página de uma resposta de duas páginas contendo 283 organizações no total. Para acessar a próxima página, adicione o parâmetro page=2 à sua solicitação GET, conforme mostrado abaixo:

https://analytics-calling.webexapis.com/v1/partners/cdrcountbyorg?endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z&page=2

Endpoint da API de registros

O endpoint da API Records é usado para consultar registros de chamadas ausentes para organizações específicas nas quais discrepâncias ou dados ausentes foram identificadas usando a API de reconciliação.

Fluxo recomendado: Ligue /v1/partners/cdrcountbyorgprimeiro. Em seguida, use o exato orgIdretornado cdr_counts[].orgIdao ligar /v1/partners/cdrsbyorg.

A API Records retorna registros de chamadas no formato JSON, idêntico ao formato descrito na API Detailed Call History. A carga retornada contém campos idênticos à carga útil retornada do Histórico detalhado de chamadas. Para obter mais informações sobre os campos e seus valores, consulte Relatório Webex Calling detalhado do histórico de chamadas.

A API fornece registros de chamadas que terminaram 5 minutos antes da hora atual. Para garantir que todos os registros de chamadas sejam disponibilizados, recomendamos consultar a API uma hora após a janela de horário de sua preferência.

O URL do endpoint da API Records usa o seguinte formato:

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

Parâmetros da API

  • orgId(required, string) — O ID da organização do cliente para o qual você deseja recuperar registros. O nome do parâmetro diferencia maiúsculas de minúsculas. Você pode obter IDs da organização no campo cdr_counts[].orgIdde resposta da API de reconciliação.
  • StartTime (obrigatório, string) — A data e a hora de início (UTC) do primeiro registro que você deseja coletar. Assegure-se de que:
    • Você formata a hora como YYYY-MM-DDTHH:MM:SS.mmmZ. Por exemplo, 2025-08-15T06:00:00.000Z.
    • A data e a hora de início não devem ter mais de 30 dias a partir do horário UTC atual.
    • O intervalo entre startTimee não endTimedeve exceder 12 horas em uma única solicitação de API.
  • endTime (required, string) — A data e hora de término (UTC) do último registro que você deseja coletar. Os registros são baseados na hora do relatório, que é quando a chamada é concluída. Assegure-se de que:
    • Você formata a hora como YYYY-MM-DDTHH:MM:SS.mmmZ. Por exemplo, 2025-08-15T18:00:00.000Z.
    • A data e a hora de término devem ser pelo menos 5 minutos antes do horário UTC atual e não devem ter mais de 30 dias.
    • A data e a hora de término devem ser maiores que startTimeo.
    • O intervalo entre startTimee não endTimedeve exceder 12 horas em uma única solicitação de API.
  • max (opcional, número) — Limita o número máximo de registros por página na resposta. Assegure-se de que:
    • O intervalo é de 500 a 5000. O valor padrão é 5000. Por exemplo, max=1000.
    • Se a API tiver mais registros para retornar do que o valor máximo especificado, a resposta será paginada.
    • Se um valor abaixo de 500 for especificado, ele será automaticamente ajustado até 500. Se um valor acima de 5000 for especificado, ele será ajustado para 5.000.

Paginação

Para identificar se as respostas da API estão paginadas, verifique se há um cabeçalho de link nos cabeçalhos de resposta. Se um nextlink estiver presente no cabeçalho Link, extraia-o e use o startTimeForNextFetchvalor para solicitar o próximo conjunto de registros. Se não houver um próximo link, todos os relatórios do intervalo de tempo selecionado serão coletados.

As solicitações de API para páginas subsequentes podem ser feitas imediatamente, mas devem ter uma taxa limitada a um máximo de 10 solicitações paginadas por minuto, por escopo de token.

Use processamento idempotente e desduplicação ao recuperar registros, inclusive em respostas paginadas ou janelas de reconciliação repetidas. Use reportIdcomo chave primária e reportTimepara determinar o último registro processado.

Por exemplo, se a solicitação inicial da API for:

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

então o cabeçalho do link na resposta é:

<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"

A paginação usa somente o cabeçalho rel="next"Link. Se a resposta incluir um rel="next"link, use esse URL para recuperar a próxima página de registros. Se a resposta não incluir um rel="next"link, você recuperou todos os registros disponíveis para o intervalo de tempo selecionado.

A paginação dessa API segue o padrão RFC5988 (Web Linking). Para obter mais informações, consulte Noções básicas da API REST.

Entenda os códigos de resposta do endpoint da API

Esta seção fornece uma visão geral dos códigos de resposta comuns que podem ser encontrados ao trabalhar com o endpoint da Reconciliation API e o endpoint da Records API. Esses endpoints desempenham um papel fundamental na sincronização, validação e geração de relatórios de dados. Compreender esses códigos de resposta é essencial para uma solução de problemas eficaz e para manter integrações confiáveis e estáveis.

Tabela 1. Códigos de resposta do API Endpoint

Código de resposta

Descrição do código de resposta

200

OK

400

Solicitação inválida: a solicitação era inválida ou não pode ser atendida de outra forma. Uma mensagem de erro anexa explicará melhor.

401

Não autorizado: as credenciais de autenticação estavam ausentes ou incorretas.

403

Proibido: A solicitação foi entendida, mas foi recusada ou o acesso não é permitido.

404

Não encontrado: o URI solicitado é inválido ou o recurso solicitado, como um usuário, não existe. Também retornado quando o formato solicitado não é suportado pelo método solicitado.

405

Método não permitido: a solicitação foi feita a um recurso usando um método de solicitação HTTP que não é suportado.

409

Conflito: A solicitação não pôde ser processada porque está em conflito com alguma regra estabelecida do sistema. Por exemplo, uma pessoa não pode ser adicionada a uma sala mais de uma vez.

410

Desaparecido: o recurso solicitado não está mais disponível.

415

Tipo de mídia não suportado: a solicitação foi feita a um recurso sem especificar um tipo de mídia ou usou um tipo de mídia que não é suportado.

423

Bloqueado: o recurso solicitado está temporariamente indisponível. Pode estar presente um cabeçalho Retry-After que especifica quantos segundos você precisa esperar antes de tentar a solicitação novamente.

428

Pré-condição necessária: Os arquivos não podem ser verificados em busca de malware e precisam ser baixados à força.

429

Muitas solicitações: Muitas solicitações foram enviadas em um determinado período de tempo e a solicitação teve uma taxa limitada. Um cabeçalho Retry-After deve estar presente para especificar quantos segundos você precisa esperar antes que uma solicitação bem-sucedida possa ser feita.

451

Por padrão, as solicitações analytics-calling.webexapis.comsão roteadas para os servidores regionais mais próximos. Se esses servidores hospedarem os dados da organização, a API retornará os dados. Caso contrário, a API retornará HTTP 451 e o corpo da resposta identificará o endpoint em que você pode recuperar os dados da organização.

500

Erro interno do servidor: Algo deu errado no servidor. Se o problema persistir, sinta-se à vontade para entrar em contato com a [equipe de suporte ao desenvolvedor Webex] (/explore/support).

502

Gateway incorreto: o servidor recebeu uma resposta inválida de um servidor upstream ao processar a solicitação. Tente novamente mais tarde.

503

Serviço indisponível: o servidor está sobrecarregado com solicitações. Tente novamente mais tarde.

504

Tempo limite do gateway: um servidor upstream não respondeu a tempo. Se sua consulta usa o parâmetro máximo, tente reduzi-lo.

Histórico de revisões

Histórico de revisão de documentos

Data de revisão

Fizemos as seguintes alterações no artigo

13/08/26

  • Requisito da função de endpoint da API de reconciliação: o usuário autenticador deve ser um administrador parceiro com acesso total em nível de administrador. Além disso, o acesso à API Webex Calling CDR deve estar ativado.

  • Os códigos de resposta do endpoint da API Understand foram atualizados para incluir o código de erro 451.

  • Foram adicionados os endpoints regionais para a região de Webex Calling dados da organização do cliente.

2/04/2026

  • Criou uma tabela de histórico de revisões que rastreia todas as alterações feitas ao longo do tempo.

  • As seções de endpoint da Reconciliation API e Records API foram atualizadas para incluir uma tabela ou valores de código de erro.

Este artigo foi útil?
Este artigo foi útil?