Every time someone makes a call through Cisco Webex Calling, the system generates data in the background—things like call detail records, signaling events, timestamps, which devices were involved, and some basic call quality information.
This article focuses on one straightforward question: what raw data does Webex Calling actually produce, where can you find it, and how long does Cisco keep it?
We're talking about what exists at the platform level. Because if you need to troubleshoot an issue, build something custom, or just understand what's happening under the hood, you need to know what data actually exists and how to get your hands on it.
Webex Calling data refers to the system-generated records and metadata created when calls are placed, received, or processed by the Webex Calling platform.
At a high level, this data falls into three categories:
Call Detail Records (CDRs): Structured records describing individual call events.
Call signaling and metadata: Timing, routing, endpoints, and locations involved in a call.
Basic call quality indicators: High-level quality flags and reason codes.
Importantly, this data is generated for operational and troubleshooting purposes, not for long-term analytics or historical reporting.
Native Webex Calling data is historical, not real-time. Records typically become available via the API or Control Hub approximately 1 to 5 minutes after a call ends. If you require "Live" dashboards, you must look beyond CDRs to Webhooks (telephony_calls) for active state changes.
Many administrators use the terms Webex Calling data and Webex Calling CDRs interchangeably—but they are not identical. Call Detail Records (CDRs) are a subset of Webex Calling data.
A CDR represents a single call record and typically includes:
When a call started and ended
Who was involved
How the call was routed
Whether the call completed successfully
CDRs do not provide: Aggregated trends, cross-user or cross-location analysis, historical normalization, or visual reporting. They are raw event records—not reports.
Cisco provides two native methods for retrieving Webex Calling data:
Administrators can export Webex Calling CDRs directly from Webex Control Hub as CSV files. These exports are useful for spot checks and audits but are not designed for large-scale historical review.
Cisco provides a REST-based API that returns call history data in JSON format. The API allows administrators to query calls within a defined time window (usually limited to 12-hour increments per request) and retrieve near-real-time call records.
| Feature | Control Hub (CSV) | Detailed History API (JSON) |
|---|---|---|
| Primary Format | CSV / Excel | JSON (Programmatic) |
| Typical Delay | ~5 Minutes | ~1-5 Minutes |
| Historical Range | Up to 400 Days | Rolling 30 Days |
| Technical Depth | Standard Fields | Detailed Metadata & Quality Flags |
Webex Calling call records typically include fields such as:
Call ID: Unique identifier for the call.
Call direction: Incoming or outgoing.
Call type: Internal, external, inbound, outbound.
Timestamps: Start time, answer time, and end time.
Participants: Calling and called numbers, user names, and location IDs.
Quality Flags: Basic indicators for packet loss, jitter, and latency.
Retention is one of the most important constraints of native Webex Calling data:
Control Hub CDR exports: Retained for up to 400 days.
Call History API (CDR Feed): Data is typically retrievable for 30 days after the call occurs.
Pro Pack Advantage: Organizations with the Webex Pro Pack can sometimes customize these windows for compliance, ranging from 7 to 3,600 days.
Once data ages out, it is no longer accessible through Cisco’s native tools. This retention model works well for operational support, but it is not intended for long-term trending or multi-year compliance audits.
Because Webex Calling data contains Personally Identifiable Information (PII)—such as names and phone numbers—access is strictly controlled. Administrators must have the "Webex Calling Detailed Call History API access" role enabled in Control Hub to see these records. For highly regulated industries, it is important to note that while Cisco masks PII in some UI logs, the raw CDR data often remains unmasked for audit purposes.
For large organizations, the API doesn't deliver all records at once. It uses **pagination** (500 to 5,000 records per page). If you have a high-volume environment, your scripts must handle "Retry-After" headers to avoid 429 Rate Limit errors, which Cisco enforces to ensure platform stability.
This distinction is critical. Raw Webex Calling data provides individual call records and event-level visibility for troubleshooting. It does not provide aggregated metrics, historical trend analysis, or visual dashboards. Reporting and analytics require additional processing and storage beyond what Webex Calling generates natively.
Native data access is typically sufficient when:
Troubleshooting individual calls or "dropped call" tickets.
Validating recent call activity for a specific user.
Auditing a limited time period for security investigations.
Webex Calling generates valuable raw call data and CDRs, but that data exists primarily for operational visibility, not analytics. Understanding what Webex Calling produces natively helps organizations set the right expectations and avoid data gaps.
