In dit artikel
Overzicht
Een webhookteterugroep-URL instellen
dropdown icon
Partner API-eindpunten
    API-eindpunt voor reconciliatie
    Records API-eindpunt
Inzicht in API-eindpuntresponscodes
Partner reports/templates API
Revisiegeschiedenis

Gedetailleerde gespreksgeschiedenis via webhook voor Webex-gesprekken in Partner Hub

list-menuIn dit artikel
list-menuFeedback?

Webex Calling multi-tenant (MT) partners kunnen een webhook instellen om Webex Calling-gegevens te verzamelen voor al hun klanten. Dit maakt efficiënte factuurafstemming, analyses en rapportage mogelijk zonder dat elke klant afzonderlijk hoeft te worden geraadpleegd.

Overzicht

De Detailed Call Records-webhook biedt een veilige, schaalbare en robuuste oplossing die gebaseerd is op gebeurtenissen in plaats van verzoeken. Deze webhook biedt meer inzicht in de Webex-belactiviteiten van uw klanten en ondersteunt diverse toepassingen, van facturering tot rapportages op maat.

Met deze webhook kunt u eenvoudig gegevens verzamelen voor alle klanten die via Partner Hub worden beheerd, zonder elke klant afzonderlijk te hoeven bevragen. Met deze webhook kunt u aangepaste rapportage-, facturatie- en analyseapplicaties ontwikkelen voor zowel interne bedrijfsbehoeften als diensten met toegevoegde waarde.

Voor een introductie tot de webhook en de bijbehorende API's kunt u deze videocast bekijken: Webex Calling Partner Gedetailleerde oproepgeschiedenis API.

Wat de Partner-webhook levert

De webhook levert elke 5 minuten een gedetailleerd overzicht van de gespreksgeschiedenis. Elke webhook-payload bevat:

  • Gespreksgegevens van gesprekken die tussen 10 minuten en 5 minuten vóór het huidige tijdstip zijn beëindigd.
  • Alle te laat opgenomen gegevens worden verwerkt door de Webex Calling-cloud.
  • Vult automatisch te late oproepgegevens aan in de daaropvolgende webhook-payloads om een betrouwbare levering te garanderen.

Om te laten zien hoe gespreksgegevens in elke payload worden opgenomen, kunt u het volgende voorbeeld bekijken:

  • Een lading ontvangen bij 14:05 bevat gesprekken die zijn beëindigd tussen 13:55 En 14:00.
  • Gesprekken die eindigen tussen 14:00 En 14:05 zijn opgenomen in de 14:10 lading.
  • Eerder voltooide records (bijvoorbeeld een gesprek dat eindigde om 14:04) maar later verwerkt door Webex Calling cloud (bijvoorbeeld, op 14:11) zijn opgenomen in de volgende geplande payload (bijvoorbeeld, 14:15).

De webhooks leveren betrouwbaar records aan. Het is echter mogelijk dat u dubbele records ontvangt in volgende webhook-payloads wanneer het systeem onder bepaalde omstandigheden records opnieuw afspeelt. U bent verantwoordelijk voor het verwijderen van dubbele records. Om dubbele records te identificeren, gebruikt u het veld reportId als primaire sleutel en het veld reportTime om te bepalen wanneer een gesprek is voltooid of verwerkt. Gebruik deze velden om de records in uw interne gegevensopslag bij te werken of in te voegen.

Webhook in Partner Hub

Door een webhook op te geven, stelt u het analyseplatform in staat om gespreksgegevens naar uw callback-URL te sturen zodra deze worden gegenereerd.

Webex-oproepgegevens worden geleverd in hetzelfde formaat als de bestaande Gedetailleerde oproepgegevens-API's. Je kunt een webhook instellen en kiezen tussen twee soorten feeds:

  • Analysegegevens—Omvat alle gespreksgegevens van alle klantorganisaties waarmee de partner een Webex Calling-relatie heeft. Dit omvat organisaties waar:
    • De partner beheert de klantorganisatie met een rol als Partner Full Administrator.
    • De klantorganisatie beschikt over een actief Webex Calling-abonnement binnen de partnerorganisatie.
  • Facturering—Omvat gespreksgegevens voor gesprekken die zijn gevoerd door gebruikers met een Webex Calling-licentie die door de partner is verkocht en geactiveerd. Gespreksgegevens voor Workspaces zijn in deze feed opgenomen.

Toegang en gegevensprivacy

Alleen de eigenaar-partner heeft toegang tot gespreksgegevens (Call Detail Records, CDR) voor facturering.

  • Een partner (of subpartner) die de aan het gespreksrecord gekoppelde licentie beheert, wordt de eigenaar-partner.
  • Het eigendom wordt bepaald door: Gebruikers-ID > Licentie-ID > Abonnements-ID > Partner-ID.
  • Elke CDR is toegankelijk voor één enkele partner.
  • Sommige gespreksgegevens kunnen niet aan een factureringspartner worden gekoppeld, en niet alle partners die aan een organisatie zijn verbonden, hebben gelijke toegang tot alle gegevens, aangezien deze gegevens persoonsgegevens kunnen bevatten.

Een webhookteterugroep-URL instellen

Configureer de webhook in de Partner Hub. Je kunt slechts één webhook per partnerorganisatie instellen.

Zorg ervoor dat u de volledige beheerdersrol 'Partner' hebt met 'Toegang op organisatieniveau met volledige beheerdersrechten' en dat de optie 'Webex Calling CDR API-toegang ' is aangevinkt in Control Hub (onder ' Beheer '). > Gebruikers, selecteer een volledige beheerder of partner-volledige beheerder en selecteer vervolgens Beheerdersrollen > Partner).

Schermafbeelding met de instellingen voor beheerdersrollen, waarbij 'Partner admin' en 'Partner full admin' zijn geselecteerd, en 'Webex Calling CDR API Access' is aangevinkt onder 'Functionele instellingen'.

1

Meld u aan bij Partner Hub.

2

Ga naar Organisatie-instellingen > Gespreksdetails.

Schermafbeelding van de organisatie-instellingen voor gespreksdetails, met de velden voor webhook-URL, geheim token en resourcetype, waarbij Analytics is geselecteerd.
3

Voer een URL in die u wilt gebruiken onder Webhook.

De URL moet eindigen met /webhook (Bijvoorbeeld, https://yourdomain.com/webhook).
4

Als u uw webhook-payloads wilt authenticeren met een geheim token, kunt u er een toevoegen. Voor meer informatie over Webex-webhooks en geheime tokens, zie Webex voor ontwikkelaars: Webhooks.

5

Selecteer een van de volgende brontypen die u voor de webhook wilt gebruiken:

  • Analysegegevens—Bevat alle gespreksgegevens voor alle klantorganisaties waarmee de partner een Webex Calling-relatie heeft.
  • Facturering—Bevat gespreksgegevens voor gebruikers aan wie de partner Webex Calling-licenties heeft verkocht. Gespreksgegevens voor Workspaces zijn in deze feed opgenomen.

Partner API-eindpunten

Naast de webhook biedt Webex Calling API-eindpunten ter ondersteuning van gegevensafstemming. Met deze eindpunten kunt u uw gegevensarchieven bijwerken of aanvullen met eventuele ontbrekende records die uw webhook-listener mogelijk niet heeft ontvangen. De twee API-eindpunten zijn de Reconciliation API en de Records API.

Gegevens van deze API's zijn 30 dagen beschikbaar. Om ervoor te zorgen dat u alle verwachte platen ontvangt, raden wij u aan uw archiefvoorraad periodiek te controleren, bijvoorbeeld elke 12 of 24 uur.

U moet een partner-toegangstoken gebruiken om toegang te krijgen tot deze API's. Verkrijg en beheer uw partner-toegangstoken volgens de standaard Webex Developer-toegangstokenbeheerprocedures.

De API-vensterbereiken zijn van toepassing op beide eindpunten om de servicebelasting beter te kunnen verwerken.

  • Voor tijdsperioden langer dan 48 uur is de maximaal toegestane vensterduur 12 uur (aanbevolen en verplicht).
  • Voor tijdsperioden van 48 uur of minder is de maximaal toegestane vensterduur 48 uur (niet aanbevolen; deze optie wordt per 30 januari 2026 uitgefaseerd).
  • Voor een partnerorganisatie-ID geldt een snelheidslimiet van één initiële API-aanvraag per minuut, per tokenbereik. Indien paginering wordt gebruikt, zijn maximaal 10 extra gepagineerde API-verzoeken per minuut per token toegestaan, en deze kunnen direct na het eerste verzoek worden gedaan.

API-eindpunt voor reconciliatie

Het Reconciliation API-eindpunt retourneert het totale aantal gespreksrecords dat is gegenereerd voor elke klant die door de partner wordt beheerd binnen de opgegeven periode. U kunt deze totalen gebruiken om uw lokale opslag te controleren en eventuele ontbrekende of inconsistente gespreksgegevens voor specifieke klanten te identificeren.

Als u meer dan 200 klantorganisaties beheert, pagineert de API de resultaten om de leesbaarheid te verbeteren.

De URL van het eindpunt van de Reconciliation API heeft de volgende indeling:

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

API-parameters

Je kunt de API gebruiken om gespreksgegevens van de afgelopen 30 dagen op te vragen. Het door u geselecteerde tijdsvenster moet minimaal 5 minuten vóór de huidige UTC-tijd beginnen en mag niet langer dan 12 uur tussen de begin- en eindtijd van één API-aanroep duren.

De API-parameters zijn:

  • startTime (verplicht, tekenreeks)—De startdatum en -tijd (UTC) voor de eerste record die u wilt verzamelen. Zorg ervoor dat:
    • Je formatteert de tijd als YYYY-MM-DDTHH:MM:SS.mmmZ. Bijvoorbeeld, 2025-08-15T06:00:00.000Z.
    • De startdatum en -tijd mogen niet ouder zijn dan 30 dagen vanaf de huidige UTC-tijd.
    • De tijdspanne tussen startTime en endTime mag niet langer zijn dan 12 uur.
  • endTime (verplicht, tekenreeks)—De einddatum en -tijd (UTC) voor de records die u wilt verzamelen. De gegevens worden geregistreerd op basis van het tijdstip waarop het gesprek is beëindigd. Zorg ervoor dat:
    • Je formatteert de tijd als YYYY-MM-DDTHH:MM:SS.mmmZ. Bijvoorbeeld, 2025-08-15T18:00:00.000Z.
    • De einddatum en -tijd moeten 5 minuten voor de huidige UTC-tijd liggen en mogen niet ouder zijn dan 30 dagen.
    • De einddatum en -tijd moeten later zijn dan de startTime.
    • De tijdspanne tussen de startTime en endTime mag niet langer zijn dan 12 uur.

Voorbeeld van een JSON-antwoord van een Reconciliation API-eindpunt:


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

De API-antwoordheaders geven het totale aantal geretourneerde organisaties aan en of er aanvullende pagina's beschikbaar zijn. Controleer de volgende headerparameters om er zeker van te zijn dat u alle pagina's hebt opgevraagd:

  • num-pagina's: Totaal aantal pagina's (bijvoorbeeld 2)
  • totaal-organisaties: Totaal aantal organisaties dat in het antwoord is opgenomen (bijvoorbeeld 283)
  • huidige pagina: Het huidige paginanummer (bijvoorbeeld 1)

Als de kopteksten bijvoorbeeld het volgende weergeven: num-pages=2, total-orgs=283, En current-page=1, U bekijkt de eerste pagina van een antwoord van twee pagina's met in totaal 283 organisaties. Om naar de volgende pagina te gaan, voeg je toe page=2 parameter voor uw GET-verzoek, zoals hieronder weergegeven:

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

Records API-eindpunt

Het Records API-eindpunt wordt gebruikt om ontbrekende gespreksgegevens op te vragen voor specifieke organisaties waar discrepanties of ontbrekende gegevens zijn vastgesteld met behulp van de Reconciliation API.

De Records API retourneert gespreksgegevens in JSON-formaat, identiek aan het formaat beschreven in de Gedetailleerde gespreksgeschiedenis API. De geretourneerde gegevens bevatten identieke velden als de gegevens die worden geretourneerd bij de gedetailleerde gespreksgeschiedenis. Voor meer informatie over de velden en hun waarden, zie Gedetailleerd gespreksgeschiedenisrapport Webex-gesprekken.

De API biedt gespreksgegevens van gesprekken die 5 minuten vóór het huidige tijdstip zijn beëindigd. Om ervoor te zorgen dat alle gespreksgegevens beschikbaar komen, raden we aan de API een uur na het door u gewenste tijdsvenster te raadplegen.

De URL van het Records API-eindpunt gebruikt het volgende formaat:

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

  • OrgID (verplicht, tekenreeks)—De organisatie-ID waarvoor u records wilt ophalen. Je kunt organisatie-ID's verkrijgen via de Reconciliation API.
  • startTime (verplicht, tekenreeks)—De startdatum en -tijd (UTC) voor de eerste record die u wilt verzamelen. Zorg ervoor dat:
    • Je formatteert de tijd als YYYY-MM-DDTHH:MM:SS.mmmZ. Bijvoorbeeld, 2025-08-15T06:00:00.000Z.
    • De startdatum en -tijd mogen niet ouder zijn dan 30 dagen vanaf de huidige UTC-tijd.
    • Het interval tussen de startTime en endTime mag in één API-verzoek niet langer zijn dan 12 uur.
  • endTime (verplicht, tekenreeks)—De einddatum en -tijd (UTC) voor de laatste record die u wilt verzamelen. De gegevens worden geregistreerd op basis van het tijdstip waarop het gesprek is beëindigd. Zorg ervoor dat:
    • Je formatteert de tijd als YYYY-MM-DDTHH:MM:SS.mmmZ. Bijvoorbeeld, 2025-08-15T18:00:00.000Z.
    • De einddatum en -tijd moeten minimaal 5 minuten voor de huidige UTC-tijd liggen en mogen niet ouder zijn dan 30 dagen.
    • De einddatum en -tijd moeten later zijn dan de startTime.
    • Het interval tussen de startTime en endTime mag in één API-verzoek niet langer zijn dan 12 uur.
  • Max (optioneel, getal)—Beperkt het maximale aantal records per pagina in het antwoord. Zorg ervoor dat:
    • Het bereik is van 500 tot 5000. De standaardwaarde is 5000. Bijvoorbeeld, Max=1000.
    • Als de API meer records moet retourneren dan de opgegeven maximale waarde, wordt het antwoord gepagineerd.
    • Als een waarde lager dan 500 wordt opgegeven, wordt deze automatisch naar 500 verhoogd. Als een waarde boven de 5000 wordt opgegeven, wordt deze naar beneden bijgesteld tot 5000.

Paginering

Om te achterhalen of API-reacties gepagineerd zijn, controleer je de reactieheaders op een Link-header. Als er een next link in de Link-header aanwezig is, haal deze dan eruit en gebruik de startTimeForNextFetch waarde om de volgende set records op te vragen. Als er geen volgende link is, worden alle rapporten voor het geselecteerde tijdsbereik verzameld.

API-verzoeken voor volgende pagina's kunnen direct worden gedaan, maar moeten worden beperkt tot maximaal 10 gepagineerde verzoeken per minuut, per tokenbereik.

Als het initiële API-verzoek bijvoorbeeld is:

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

De Link-header in het antwoord is dan:

; rel="next"

Andere mogelijke linkwaarden zijn rel="first" en rel="prev" voor respectievelijk de eerste en vorige pagina.

De paginering voor deze API volgt de RFC5988 (Web Linking)-standaard. Voor meer informatie, zie Basisprincipes van de REST API.

Inzicht in API-eindpuntresponscodes

Deze sectie biedt een overzicht van veelvoorkomende responscodes die kunnen worden aangetroffen bij het werken met het Reconciliation API-eindpunt en het Records API-eindpunt. Deze eindpunten spelen een cruciale rol in de synchronisatie, validatie en rapportage van gegevens. Inzicht in deze responscodes is essentieel voor effectieve probleemoplossing en voor het handhaven van betrouwbare, stabiele integraties.

Tabel 1. API-eindpunt-responscodes

Reactiecode

Beschrijving van de responscode

200

OK

400

Slecht verzoek: Het verzoek was ongeldig of kan op geen enkele andere manier worden ingewilligd. Een bijbehorend foutbericht geeft verdere uitleg.

401

Niet geautoriseerd: De authenticatiegegevens ontbraken of waren onjuist.

403

Verboden: Het verzoek is begrepen, maar is afgewezen of de toegang is niet toegestaan.

404

Niet gevonden: De opgevraagde URI is ongeldig of de gevraagde bron, zoals een gebruiker, bestaat niet. Deze retourwaarde wordt ook geretourneerd wanneer het gevraagde formaat niet wordt ondersteund door de gevraagde methode.

405

Methode niet toegestaan: Het verzoek werd gedaan aan een bron met behulp van een HTTP-verzoekmethode die niet wordt ondersteund.

409

Conflict: Het verzoek kon niet worden verwerkt omdat het in strijd is met een vastgestelde systeemregel. Een persoon mag bijvoorbeeld niet meer dan één keer aan een kamer worden toegevoegd.

410

Verdwenen: De gevraagde bron is niet langer beschikbaar.

415

Niet-ondersteund mediatype: Er is een verzoek gedaan aan een bron zonder een mediatype te specificeren, of er is een mediatype gebruikt dat niet wordt ondersteund.

423

Vergrendeld: De gevraagde bron is tijdelijk niet beschikbaar. Er kan een Retry-After-header aanwezig zijn die aangeeft hoeveel seconden er gewacht moet worden voordat de aanvraag opnieuw wordt geprobeerd.

428

Vereiste voorwaarde: De bestanden kunnen niet op malware worden gescand en moeten geforceerd worden gedownload.

429

Te veel verzoeken: Er zijn te veel verzoeken verzonden binnen een bepaalde tijdsperiode, waardoor de verwerkingstijd van het verzoek is beperkt. Er moet een Retry-After-header aanwezig zijn die aangeeft hoeveel seconden er gewacht moet worden voordat een succesvol verzoek kan worden verwerkt.

500

Interne serverfout: Er is iets misgegaan op de server. Mocht het probleem aanhouden, neem dan gerust contact op met de [Webex Ontwikkelaarsondersteuning team](/explore/support).

502

Bad Gateway: De server ontving een ongeldige reactie van een upstream-server tijdens de verwerking van het verzoek. Probeer het later opnieuw.

503

Service niet beschikbaar: De server is overbelast met aanvragen. Probeer het later opnieuw.

504

Gateway-time-out: Een upstream-server reageerde niet op tijd. Als uw query de parameter 'max' gebruikt, probeer deze dan te verlagen.

Partner reports/templates API

U kunt rapporten die beschikbaar zijn in Partner Hub genereren en downloaden met behulp van de Partner Reports API's. Voor meer informatie, zie de partner report/templates.

Partners kunnen ook rechtstreeks vanuit Partner Hub diverse rapporten inzien en downloaden. Voor meer informatie, zie Partner Hub-rapporten.

Revisiegeschiedenis

Revisiegeschiedenis van het document

Revisiedatum

We hebben de volgende wijzigingen in het artikel aangebracht.

1/14/2026

  • Ik heb een revisiegeschiedenistabel gemaakt die alle wijzigingen bijhoudt die in de loop der tijd zijn aangebracht.

  • De secties over het Reconciliation API-eindpunt en het Records API-eindpunt zijn bijgewerkt met een tabel met foutcodewaarden.

Vond u dit artikel nuttig?
Vond u dit artikel nuttig?