Merci pour votre commentaire.

Le webhook Detailed Call Records propose une solution sécurisée, évolutive et robuste axée sur les événements plutôt que sur les demandes. Ce webhook offre une meilleure visibilité sur les Webex Calling activités de vos clients, en prenant en charge des cas d'utilisation, de la facturation aux rapports personnalisés.

Vous pouvez utiliser ce webhook pour recueillir facilement des données pour tous les clients gérés via Partner Hub, sans demander à chaque client un par un. Ce webhook vous permet de développer des applications personnalisées de reporting, de facturation et d'analyse pour les besoins commerciaux internes et les services à valeur ajoutée.

Pour une présentation du webhook et des API qui l'accompagnent, regardez ce Vidcast : API d'historique détaillé des appels pour les Webex Calling partenaires.

Ce que propose le webhook Partner

Le webhook fournit un historique détaillé des appels toutes les 5 minutes. Chaque charge utile de webhook contient  :

• Enregistrements d'appels qui se sont terminés entre 10 minutes et 5 minutes avant l'heure actuelle.
• Tout enregistrement en retard traité par le Webex Calling cloud.
• Remplit automatiquement les enregistrements d'appels en retard dans les charges utiles du Webhook suivantes afin de garantir une livraison fiable.

Pour montrer comment les enregistrements d'appels sont inclus dans chaque charge utile, prenons l'exemple suivant :

• Une charge utile reçue à 14h05 contient des appels qui se sont terminés entre 13h55 et 14h00.
• Les appels se terminant entre 14h00 et 14h05 sont inclus dans la charge utile de 14h10.
• Les enregistrements terminés plus tôt (par exemple, un appel qui s'est terminé à 14h04) mais traités tardivement par le Webex Calling cloud (par exemple, à 14h11) sont inclus dans la charge utile planifiée suivante ( par exemple, 14h15).

Webhook dans Partner Hub

En fournissant un webhook, vous permettez à la plateforme d'analyse d'envoyer les enregistrements d'appels vers votre URL de rappel dès qu'ils sont générés.

Webex Callingles enregistrements sont transmis dans le même format que les API Detailed Call Records existantes. Vous pouvez créer un webhook et choisir entre deux types de flux :

• Analytique : inclut tous les enregistrements d'appels de toutes les organisations clientes avec lesquelles le partenaire entretient une Webex Calling relation. Cela inclut les organisations dans lesquelles :
  • Le partenaire gère l'organisation cliente avec le rôle d'administrateur à part entière.
  • L'organisation cliente possède un Webex Calling abonnement actif au sein de l'organisation partenaire.
• Facturation : inclut les enregistrements des appels passés par les utilisateurs titulaires d'une Webex Calling licence vendue et fournie par le partenaire. Les relevés d'appels pour Workspaces sont inclus dans ce fil.

Accès et confidentialité des données

Seul le partenaire propriétaire peut accéder aux enregistrements détaillés des appels (CDR) pour la facturation.

• Un partenaire (ou un sous-partenaire) qui gère la licence associée à l'enregistrement des appels devient le partenaire propriétaire.
• La propriété est déterminée par : ID utilisateur > ID de licence > ID d'abonnement > ID partenaire.
• Chaque CDR est accessible à un seul partenaire.
• Certains enregistrements d'appels ne correspondent pas à un partenaire de facturation, et tous les partenaires associés à une organisation n'ont pas le même accès à tous les enregistrements, car ceux-ci peuvent contenir des informations personnelles identifiables (PII).

Outre le webhook, il Webex Calling fournit des points de terminaison d'API pour faciliter la réconciliation des données. Ces points de terminaison vous permettent de rattraper ou de réconcilier vos banques de données avec les enregistrements manquants que votre auditeur Webhook n'aurait peut-être pas reçus. Les deux points de terminaison de l'API sont l'API de réconciliation et l'API Records.

Les enregistrements de ces API sont disponibles pendant 30 jours. Pour vous assurer de recevoir tous les disques attendus, nous vous recommandons de réconcilier vos disquaires régulièrement, par exemple toutes les 12 ou 24 heures.

Vous devez utiliser un jeton d'accès partenaire pour accéder à ces API. L'utilisateur qui s'authentifie doit être un administrateur partenaire à part entière avec un accès organisationnel complet au niveau administrateur et l'accès à l'API Webex Calling CDR doit être activé. Le jeton OAuth doit inclure le spark-admin:calling_cdr_readscope. Les rôles d'administrateur en lecture seule ne sont pas suffisants pour les API Partner Reconciliation and Records.

Utilisez le analytics-callingpoint de terminaison correspondant à la région de Webex Calling données de l'organisation cliente. Utilisez l'URL de base applicable pour les API de réconciliation et d'enregistrement :

• États-Unis et Canada : https://analytics-calling.webexapis.com
• Europe : https://analytics-calling-eu.webexapis.com
• Inde : https://analytics-calling-in.webexapis.com
• Australie : https://analytics-calling-au.webexapis.com

Point de terminaison de l'API de réconciliation

Le point de terminaison de l'API de réconciliation renvoie le nombre total d'enregistrements d'appels générés pour chaque client géré par le partenaire au cours de la période spécifiée. Vous pouvez utiliser ces totaux pour vérifier votre stockage local et identifier les enregistrements d'appels manquants ou incohérents pour des clients spécifiques.

Si vous gérez plus de 200 organisations clientes, l'API pagine les résultats pour en améliorer la lisibilité.

L'URL du point de terminaison de l'API de réconciliation utilise le format suivant :

Paramètres de l'API

Vous pouvez utiliser l'API pour récupérer les enregistrements d'appels des 30 derniers jours. La fenêtre horaire que vous avez sélectionnée doit commencer au moins 5 minutes avant l'heure UTC actuelle et ne peut pas dépasser 12 heures entre le début et la fin d'un seul appel d'API.

Les paramètres de l'API sont les suivants :

• StartTime (obligatoire, chaîne) : date et heure de début (UTC) du premier enregistrement que vous souhaitez collecter. Assurez-vous que :
  • Vous formatez l'heure comme suit YYYY-MM-DDTHH:MM:SS.mmmZ: Par exemple, 2025-08-15T06:00:00.000Z.
  • La date et l'heure de début ne doivent pas dater de plus de 30 jours par rapport à l'heure UTC actuelle.
  • La fenêtre entre startTimeet ne endTimepeut pas dépasser 12 heures.
• EndTime (obligatoire, chaîne) : date et heure de fin (UTC) des enregistrements que vous souhaitez collecter. Les records sont basés sur l'heure du rapport, c'est-à-dire la fin de l'appel. Assurez-vous que :
  • Vous formatez l'heure comme suit YYYY-MM-DDTHH:MM:SS.mmmZ: Par exemple, 2025-08-15T18:00:00.000Z.
  • La date et l'heure de fin doivent être 5 minutes avant l'heure UTC actuelle et pas plus de 30 jours.
  • La date et l'heure de fin doivent être supérieures au startTime.
  • La fenêtre entre le startTimeet ne endTimepeut pas dépasser 12 heures.

Exemple de réponse JSON au point de terminaison de l'API de réconciliation :

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

Les en-têtes des réponses de l'API indiquent le nombre total d'organisations renvoyées et indiquent si des pages supplémentaires sont disponibles. Vérifiez les paramètres d'en-tête suivants pour vous assurer que vous avez interrogé toutes les pages :

• num-pages : nombre total de pages (par exemple, 2)
• total-orgs : nombre total d'organisations incluses dans la réponse (par exemple, 283)
• page actuelle : Le numéro de la page actuelle (par exemple, 1)

Par exemple, si les en-têtes indiquent num-pages=2, total-orgs=283 et current-page=1, vous consultez la première page d'une réponse de deux pages contenant 283 organisations au total. Pour accéder à la page suivante, ajoutez le paramètre page=2 à votre requête GET, comme indiqué ci-dessous :

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

Enregistre le point final de l'API

Le point de terminaison de l'API Records est utilisé pour interroger les enregistrements d'appels manquants pour des organisations spécifiques où des divergences ou des données manquantes ont été identifiées à l'aide de l'API de réconciliation.

Flux recommandé : appelez /v1/partners/cdrcountbyorgd'abord. Ensuite, utilisez la date exacte que vous avez orgIdrenvoyée cdr_counts[].orgIdlorsque vous appelez /v1/partners/cdrsbyorg.

L'API Records renvoie les enregistrements d'appels au format JSON, identique au format décrit dans l'API d'historique détaillé des appels. La charge utile renvoyée contient des champs identiques à ceux de la charge utile renvoyée par l'historique détaillé des appels. Pour plus d'informations sur les champs et leurs valeurs, voir le rapport Webex Calling détaillé sur l'historique des appels.

L'API fournit des enregistrements d'appels qui se sont terminés 5 minutes avant l'heure actuelle. Pour vous assurer que tous les enregistrements d'appels sont disponibles, nous vous recommandons de consulter l'API une heure après la fenêtre horaire de votre choix.

L'URL du point de terminaison de l'API Records utilise le format suivant :

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

Paramètres de l'API

• orgId(obligatoire, chaîne) : identifiant de l'organisation cliente pour laquelle vous souhaitez récupérer des enregistrements. Le nom du paramètre distingue les majuscules et minuscules. Vous pouvez obtenir les identifiants des organisations dans le champ de réponse de l'API de réconciliation cdr_counts[].orgId.
• StartTime (obligatoire, chaîne) : date et heure de début (UTC) du premier enregistrement que vous souhaitez collecter. Assurez-vous que :
  • Vous formatez l'heure comme suit YYYY-MM-DDTHH:MM:SS.mmmZ: Par exemple, 2025-08-15T06:00:00.000Z.
  • La date et l'heure de début ne doivent pas dater de plus de 30 jours par rapport à l'heure UTC actuelle.
  • L'intervalle entre le startTimeet ne endTimedoit pas dépasser 12 heures pour une seule demande d'API.
• EndTime (obligatoire, chaîne) : date et heure de fin (UTC) du dernier enregistrement que vous souhaitez collecter. Les records sont basés sur l'heure du rapport, c'est-à-dire la fin de l'appel. Assurez-vous que :
  • Vous formatez l'heure comme suit YYYY-MM-DDTHH:MM:SS.mmmZ: Par exemple, 2025-08-15T18:00:00.000Z.
  • La date et l'heure de fin doivent être situées au moins 5 minutes avant l'heure UTC actuelle et pas plus de 30 jours.
  • La date et l'heure de fin doivent être supérieures au startTime.
  • L'intervalle entre le startTimeet ne endTimedoit pas dépasser 12 heures pour une seule demande d'API.
• max (facultatif, nombre) : limite le nombre maximum d'enregistrements par page dans la réponse. Assurez-vous que :
  • La fourchette va de 500 à 5 000. La valeur par défaut est 5 000. Par exemple, max=1000.
  • Si l'API a plus d'enregistrements à renvoyer que la valeur maximale spécifiée, la réponse est paginée.
  • Si une valeur inférieure à 500 est spécifiée, elle est automatiquement ajustée à 500. Si une valeur supérieure à 5 000 est spécifiée, elle est ramenée à 5 000.

Pagination

Pour savoir si les réponses de l'API sont paginées, vérifiez que les en-têtes de réponse contiennent un en-tête de lien. Si un nextlien est présent dans l'en-tête du lien, extrayez-le et utilisez startTimeForNextFetchsa valeur pour demander la prochaine série d'enregistrements. S'il n'y a pas de lien suivant, tous les rapports pour la période sélectionnée sont collectés.

Les demandes d'API pour les pages suivantes peuvent être effectuées immédiatement, mais le débit doit être limité à un maximum de 10 requêtes paginées par minute, par jeton.

Utilisez le traitement idempotent et la déduplication lorsque vous récupérez des enregistrements, y compris dans le cadre de réponses paginées ou de fenêtres de rapprochement répétées. reportIdUtilisez-la comme clé primaire et reportTimepour déterminer le dernier enregistrement traité.

Par exemple, si la demande d'API initiale est :

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

alors l'en-tête du lien dans la réponse est :

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

La pagination utilise uniquement l'en-tête du rel="next"lien. Si la réponse inclut un rel="next"lien, utilisez cet URL pour accéder à la page suivante des records. Si la réponse ne contient pas de rel="next"lien, vous avez récupéré tous les enregistrements disponibles pour la période sélectionnée.

Vous pouvez générer et télécharger des rapports disponibles sur Partner Hub à l'aide des API Partner Reports. Pour plus d'informations, consultez le rapport/les modèles des partenaires.

Les partenaires peuvent également accéder à plusieurs rapports et les télécharger directement depuis Partner Hub. Pour plus d' informations, consultez les rapports du Partner Hub.