- Página inicial
- /
- Artigo
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 verificado no Control Hub (em Gerenciamento > , 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.
| 1 |
Faça login no Partner Hub. |
| 2 |
Vá para .
|
| 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:
|
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ãoendTimepode exceder 12 horas.
- Você formata a hora como
-
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ãoendTimepode exceder 12 horas.
- Você formata a hora como
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 campocdr_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ãoendTimedeve exceder 12 horas em uma única solicitação de API.
- Você formata a hora como
-
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ãoendTimedeve exceder 12 horas em uma única solicitação de API.
- Você formata a hora como
-
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.
- O intervalo é de 500 a 5000. O valor padrão é 5000. Por exemplo,
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.
|
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 |
|
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. |
API de relatórios/modelos de parceiros
Você pode gerar e baixar relatórios disponíveis no Partner Hub usando as APIs de relatórios do parceiro. Para obter mais informações, consulte o relatório/modelos do parceiro.
Os parceiros também podem acessar e baixar vários relatórios diretamente do Partner Hub. Para obter mais informações, consulte os relatórios do Partner Hub.
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 |
|
|
2/04/2026 |
|