- Home
- /
- Articolo
I partner multi-tenant (MT) Webex Calling possono creare un webhook per raccogliere i record Webex Calling per tutti i suoi clienti. Ciò consente una riconciliazione delle fatture, un'analisi e una reportistica efficienti senza dover interrogare ogni cliente individualmente.
Panoramica
Il webhook Detailed Call Records offre una soluzione sicura, scalabile e robusta basata sugli eventi anziché sulle richieste. Questo webhook offre una maggiore visibilità sulle Webex Calling attività dei suoi clienti, supportando i casi d'uso, dalla fatturazione ai report personalizzati.
Può utilizzare questo webhook per raccogliere comodamente i record di tutti i clienti gestiti tramite Partner Hub senza interrogare ogni cliente individualmente. Questo webhook Le consente di sviluppare applicazioni personalizzate di reporting, fatturazione e analisi sia per i requisiti aziendali interni che per i servizi a valore aggiunto.
Per un'introduzione al webhook e alle relative API, guardi questa API di cronologia dettagliata delle chiamate di Vidcast: Webex Calling Partner.
Cosa offre il webhook Partner
Il webhook fornisce registrazioni dettagliate della cronologia delle chiamate ogni 5 minuti. Ogni payload del webhook contiene :
- Registrazioni delle chiamate terminate tra 10 minuti e 5 minuti prima dell'ora corrente.
- Qualsiasi registrazione tardiva elaborata dal Webex Calling cloud.
- Riempie automaticamente i registri delle chiamate in ritardo nei successivi payload del webhook per garantire una consegna affidabile.
Per mostrare come i registri delle chiamate sono inclusi in ogni payload, consideri il seguente esempio:
- Un payload ricevuto alle 14:05 contiene chiamate terminate tra le 13:55 e le 14:00.
- Le chiamate che terminano tra le 14:00 e le 14:05 sono incluse nel payload delle 14:10.
- I record completati in precedenza (ad esempio, una chiamata terminata alle 14:04) ma elaborati in ritardo dal Webex Calling cloud (ad esempio, alle 14:11) sono inclusi nel payload programmato successivo ( ad esempio, 14:15).
I webhook forniscono record in modo affidabile. Tuttavia, potrebbe ricevere record duplicati nei payload successivi dei webhook quando il sistema riproduce i record in determinate condizioni. Lei è responsabile della gestione della deduplicazione dei record. Per identificare i record duplicati, utilizzi il campo ReportID come chiave primaria e il campo ReportTime per determinare quando una chiamata è stata completata o elaborata. Usa questi campi per aggiornare o inserire i record nei suoi archivi dati interni.
Webhook nel Partner Hub
Fornendo un webhook, consente alla piattaforma di analisi di inviare i record delle chiamate al suo URL di callback ogni volta che vengono generati.
Webex Callingi record vengono consegnati utilizzando lo stesso formato delle API Detailed Call Records esistenti. Può configurare un webhook e scegliere tra due tipi di feed:
- Analisi: include tutti i registri delle chiamate per tutte le organizzazioni clienti con cui il partner ha una Webex Calling relazione. Ciò include le organizzazioni in cui:
- Il partner gestisce l'organizzazione del cliente con il ruolo di Amministratore completo del partner.
- L'organizzazione cliente ha un Webex Calling abbonamento attivo all'interno dell'organizzazione partner.
- Fatturazione: include i registri delle chiamate effettuate dagli utenti con una Webex Calling licenza venduta e fornita dal partner. I registri delle chiamate per Workspaces sono inclusi in questo feed.
Accesso e privacy dei dati
Solo il partner proprietario può accedere ai Call Detail Records (CDR) per la fatturazione.
- Un partner (o subpartner) che gestisce la licenza associata al registro delle chiamate diventa il partner proprietario.
- La proprietà è determinata da: ID utente > ID licenza > ID abbonamento > ID partner.
- Ogni CDR è accessibile a un singolo partner.
- Alcuni registri delle chiamate non corrispondono a un partner di fatturazione e non tutti i partner associati a un' organizzazione hanno lo stesso accesso a tutti i record, poiché questi record possono contenere informazioni di identificazione personale (PII).
Configurare un URL di callback per il webhook
Configura il webhook nel Partner Hub. Può configurare un solo webhook per organizzazione partner.
Si assicuri di avere il ruolo di amministratore completo del Partner con « Accesso completo a livello di amministratore organizzativo» e selezionato in Control Hub (in Gestione > , seleziona un amministratore completo o un amministratore completo del partner, quindi seleziona Ruoli di amministratore > Partner).
Gli stessi requisiti di accesso si applicano quando utilizza le API Partner Reconciliation and Records.
| 1 |
Accedi a Partner Hub. |
| 2 |
Vai a .
|
| 3 |
Inserisca un URL da utilizzare in Webhook. L'URL deve terminare con /webhook (ad esempio, https://yourdomain.com/webhook).
|
| 4 |
Se desidera autenticare i payload dei suoi webhook con un token segreto, può aggiungerne uno. Per ulteriori informazioni sui webhook e sui token segreti Webex, vedere Webex per sviluppatori: Webhooks. |
| 5 |
Seleziona uno dei seguenti tipi di risorsa da utilizzare per il webhook:
|
Endpoint delle API dei partner
Oltre al webhook, Webex Calling fornisce endpoint API per supportare la riconciliazione dei dati. Questi endpoint Le consentono di recuperare o riconciliare i suoi archivi di dati con eventuali record mancanti che il suo ascoltatore di webhook potrebbe non aver ricevuto. I due endpoint API sono l'API di riconciliazione e l'API Records.
I record di queste API sono disponibili per 30 giorni. Per assicurarci di ricevere tutti i record previsti, le consigliamo di riconciliare i suoi negozi di dischi periodicamente, ad esempio ogni 12 o 24 ore.
È necessario utilizzare un token di accesso partner per accedere a queste API. L'utente che esegue l'autenticazione deve essere un Partner Full Administrator con accesso completo a livello di amministratore organizzativo e deve avere l'accesso all'API Webex Calling CDR abilitato. Il token OAuth deve includere l'spark-admin:calling_cdr_readambito. I ruoli di amministratore di sola lettura non sono sufficienti per le API Partner Reconciliation and Records.
Usa l'analytics-callingendpoint per l'area Webex Calling dati dell'organizzazione del cliente. Utilizza l'URL di base applicabile per le API Reconciliation e Records:
- Stati Uniti e Canada:
https://analytics-calling.webexapis.com - Europa:
https://analytics-calling-eu.webexapis.com - India:
https://analytics-calling-in.webexapis.com - Australia:
https://analytics-calling-au.webexapis.com
Gli intervalli delle finestre delle API sono applicabili a entrambi gli endpoint per gestire meglio il carico del servizio.
- Per intervalli di tempo superiori a 48 ore, la durata massima consentita della finestra è di 12 ore (applicata).
- Per l'ID di un'organizzazione partner, le API sono limitate a una richiesta API iniziale al minuto, per ambito di token. Se si utilizza l'impaginazione, sono consentite fino a 10 richieste API impaginate aggiuntive al minuto, per token, che possono essere effettuate immediatamente dopo la richiesta iniziale.
Endpoint dell'API di riconciliazione
L'endpoint dell'API di riconciliazione restituisce il numero totale di registrazioni delle chiamate generate per ogni cliente gestito dal partner entro il periodo di tempo specificato. Può utilizzare questi totali per verificare la sua memoria locale e identificare eventuali registrazioni delle chiamate mancanti o incoerenti per clienti specifici.
Requisiti di accesso: l'utente che esegue l'autenticazione deve essere un amministratore partner con accesso completo a livello di amministratore e deve avere l'accesso all'API Webex Calling CDR abilitato. Il token di accesso deve includere l'spark-admin:calling_cdr_readambito.
Se gestisce più di 200 organizzazioni di clienti, l'API impagina i risultati per migliorare la leggibilità.
L'URL dell'endpoint dell'API di riconciliazione utilizza il seguente formato:
https://analytics-calling.webexapis.com/v1/partners/cdrcountbyorg?endTime=YYYY-MM-DDTHH:MM:SS.000Z&startTime=YYYY-MM-DDTHH:MM:SS.000Z
Parametri API
Può utilizzare l'API per recuperare i registri delle chiamate degli ultimi 30 giorni. La finestra oraria selezionata deve iniziare almeno 5 minuti prima dell'ora UTC corrente e non può superare le 12 ore tra l'ora di inizio e di fine in una singola chiamata API.
I parametri dell'API sono:
-
startTime (obbligatorio, stringa): la data e l'ora di inizio (UTC) del primo record che desidera raccogliere. Si assicuri che:
- Formatta l'ora come
YYYY-MM-DDTHH:MM:SS.mmmZ. Ad esempio,2025-08-15T06:00:00.000Z.
- La data e l'ora di inizio non devono essere più vecchie di 30 giorni dall'ora UTC corrente.
- La finestra tra
startTimee nonendTimepuò superare le 12 ore.
- Formatta l'ora come
-
EndTime (obbligatorio, stringa): la data e l'ora di fine (UTC) dei record che desidera raccogliere. I registri si basano sull'ora del rapporto, ovvero quando la chiamata è terminata. Si assicuri che:
- Formatta l'ora come
YYYY-MM-DDTHH:MM:SS.mmmZ. Ad esempio,2025-08-15T18:00:00.000Z. - La data e l'ora di fine devono essere 5 minuti prima dell'ora UTC corrente e non più vecchie di 30 giorni.
- La data e l'ora di fine devono essere successive al
startTime. - La finestra tra
startTimee nonendTimepuò superare le 12 ore.
- Formatta l'ora come
Esempio di risposta JSON dell'endpoint dell'API di riconciliazione:
{
"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
}
]
}
Le intestazioni delle risposte dell'API indicano il numero totale di organizzazioni restituite e se sono disponibili pagine aggiuntive. Controlli i seguenti parametri dell'intestazione per assicurarsi di aver interrogato tutte le pagine:
- num-pages: numero totale di pagine (ad esempio, 2)
- total-orgs: Numero totale di organizzazioni incluse nella risposta (ad esempio, 283)
- pagina corrente: il numero di pagina corrente (ad esempio, 1)
Ad esempio, se le intestazioni mostrano num-pages=2, total-orgs=283 e current-page=1, sta visualizzando la prima pagina di una risposta di due pagine contenente 283 organizzazioni in totale. Per accedere alla pagina successiva, aggiunga il parametro page=2 alla sua richiesta GET, come mostrato di seguito:
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 API dei record
L'endpoint Records API viene utilizzato per interrogare i record delle chiamate mancanti per organizzazioni specifiche in cui sono state identificate discrepanze o dati mancanti utilizzando l'API di riconciliazione.
Flusso consigliato: chiami /v1/partners/cdrcountbyorgprima. Quindi usi l'esatto orgIdrestituito cdr_counts[].orgIdquando chiama /v1/partners/cdrsbyorg.
L'API Records restituisce i record delle chiamate in formato JSON, identico al formato descritto nell'API Cronologia dettagliata delle chiamate. Il payload restituito contiene campi identici al payload restituito dalla cronologia dettagliata delle chiamate. Per ulteriori informazioni sui campi e sui relativi valori, vedere Rapporto Webex Calling dettagliato sulla cronologia delle chiamate.
L'API fornisce i registri delle chiamate terminati 5 minuti prima dell'ora corrente. Per garantire che tutti i registri delle chiamate siano disponibili, consigliamo di interrogare l'API un'ora dopo la sua finestra oraria preferita.
L'URL dell'endpoint Records API utilizza il seguente 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
Parametri API
-
orgId(obbligatorio, stringa): l'ID dell'organizzazione del cliente per cui desidera recuperare i record. Il nome del parametro fa distinzione tra maiuscole e minuscole. Può ottenere gli ID dell'organizzazione dal campo di risposta dell'API di riconciliazione.cdr_counts[].orgId -
startTime (obbligatorio, stringa): la data e l'ora di inizio (UTC) del primo record che desidera raccogliere. Si assicuri che:
- Formatta l'ora come
YYYY-MM-DDTHH:MM:SS.mmmZ. Ad esempio,2025-08-15T06:00:00.000Z. - La data e l'ora di inizio non devono essere più vecchie di 30 giorni dall'ora UTC corrente.
- L'intervallo tra
startTimee nonendTimedeve superare le 12 ore in una singola richiesta API.
- Formatta l'ora come
-
EndTime (obbligatorio, stringa): la data e l'ora di fine (UTC) dell'ultimo record che desidera raccogliere. I registri si basano sull'ora del rapporto, ovvero quando la chiamata è terminata. Si assicuri che:
- Formatta l'ora come
YYYY-MM-DDTHH:MM:SS.mmmZ. Ad esempio,2025-08-15T18:00:00.000Z. - La data e l'ora di fine devono essere almeno 5 minuti prima dell'ora UTC corrente e non più vecchie di 30 giorni.
- La data e l'ora di fine devono essere successive al
startTime. - L'intervallo tra
startTimee nonendTimedeve superare le 12 ore in una singola richiesta API.
- Formatta l'ora come
-
max (opzionale, numero) —Limita il numero massimo di record per pagina nella risposta. Si assicuri che:
- L'intervallo va da 500 a 5000. Il valore predefinito è 5000. Ad esempio,
max=1000. - Se l'API ha più record da restituire rispetto al valore massimo specificato, la risposta viene impaginata.
- Se viene specificato un valore inferiore a 500, viene automaticamente portato a 500. Se viene specificato un valore superiore a 5000, viene ridotto a 5000.
- L'intervallo va da 500 a 5000. Il valore predefinito è 5000. Ad esempio,
Impaginazione
Per identificare se le risposte dell'API sono impaginate, controlli le intestazioni delle risposte per un'intestazione Link. Se è presente un nextlink nell'intestazione Link, lo estragga e usi il startTimeForNextFetchvalore per richiedere il set di record successivo. Se non c'è un link successivo, vengono raccolti tutti i report per l'intervallo di tempo selezionato.
Le richieste API per le pagine successive possono essere effettuate immediatamente, ma devono essere limitate a un massimo di 10 richieste impaginate al minuto, per ambito di token.
Usa l'elaborazione e la deduplicazione idempotenti quando recupera i record, anche tra risposte impaginate o finestre di riconciliazione ripetute. Utilizzare reportIdcome chiave primaria e reportTimeper determinare l'ultimo record elaborato.
Ad esempio, se la richiesta API iniziale è:
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
allora l'intestazione del Link nella risposta è:
<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"
Pagination utilizza solo l'intestazione rel="next"Link. Se la risposta include un rel="next"link, usi quell'URL per recuperare la pagina successiva dei record. Se la risposta non include un rel="next"link, ha recuperato tutti i record disponibili per l'intervallo di tempo selezionato.
L'impaginazione per questa API segue lo standard RFC5988 (Web Linking). Per ulteriori informazioni, vedere Nozioni di base sull'API REST.
Comprendere i codici di risposta degli endpoint delle API
Questa sezione fornisce una panoramica dei codici di risposta più comuni che si possono incontrare quando si lavora con l'endpoint Reconciliation API e l'endpoint Records API. Questi endpoint svolgono un ruolo fondamentale nella sincronizzazione, convalida e reporting dei dati. La comprensione di questi codici di risposta è essenziale per una risoluzione efficace dei problemi e per mantenere integrazioni affidabili e stabili.
|
Codice di risposta |
Descrizione del codice di risposta |
|---|---|
|
200 |
OK |
|
400 |
Richiesta errata: La richiesta non era valida o non può essere soddisfatta diversamente. Un messaggio di errore allegato spiegherà ulteriormente. |
|
401 |
Non autorizzato: le credenziali di autenticazione erano mancanti o errate. |
|
403 |
Vietato: La richiesta è compresa, ma è stata rifiutata o l'accesso non è consentito. |
|
404 |
Non trovato: L'URI richiesto non è valido o la risorsa richiesta, ad esempio un utente, non esiste. Restituito anche quando il formato richiesto non è supportato dal metodo richiesto. |
|
405 |
Metodo non consentito: La richiesta è stata effettuata a una risorsa utilizzando un metodo di richiesta HTTP non supportato. |
|
409 |
Conflitto: La richiesta non può essere elaborata perché è in conflitto con alcune regole consolidate del sistema. Ad esempio, una persona non può essere aggiunta a una camera più di una volta. |
|
410 |
Andata: la risorsa richiesta non è più disponibile. |
|
415 |
Tipo di supporto non supportato: La richiesta è stata effettuata a una risorsa senza specificare un tipo di supporto o ha utilizzato un tipo di supporto non supportato. |
|
423 |
Bloccato: La risorsa richiesta è temporaneamente non disponibile. Potrebbe essere presente un'intestazione Retry-After che specifica quanti secondi deve attendere prima di tentare nuovamente la richiesta. |
|
428 |
Presupposto richiesto: i file non possono essere scansionati alla ricerca di malware e devono essere scaricati forzatamente. |
|
429 |
Troppe richieste: Sono state inviate troppe richieste in un determinato lasso di tempo e la frequenza della richiesta è limitata. Dovrebbe essere presente un'intestazione Retry-After che specifichi quanti secondi deve attendere prima di poter effettuare una richiesta con successo. |
|
451 |
Per impostazione predefinita, le richieste |
|
500 |
Errore interno del server: qualcosa è andato storto sul server. Se il problema persiste, si senta libero di contattare il [team di assistenza per sviluppatori Webex] (/explore/support). |
|
502 |
Bad Gateway: Il server ha ricevuto una risposta non valida da un server upstream durante l'elaborazione della richiesta. Riprovi più tardi. |
|
503 |
Servizio non disponibile: il server è sovraccarico di richieste. Riprovi più tardi. |
|
504 |
Gateway Timeout: Un server upstream non ha risposto in tempo. Se la sua richiesta utilizza il parametro max, provi a ridurlo. |
API per rapporti/modelli per i partner
Può generare e scaricare i report disponibili in Partner Hub utilizzando le API Partner Reports. Per ulteriori informazioni, consulti il rapporto/i modelli per i partner.
I partner possono anche accedere e scaricare più report direttamente da Partner Hub. Per ulteriori informazioni, consulti i report di Partner Hub.
Cronologia delle revisioni
Cronologia delle revisioni dei documenti
|
Data di revisione |
Abbiamo apportato le seguenti modifiche all'articolo |
|---|---|
|
13/08/26 |
|
|
2/04/2026 |
|