# The Webex Calling Detailed Call History API Canonical: https://warmtransfer.net/knowledge/webex-calling-cdr Last verified: 2026-09-16 The Webex Calling Detailed Call History API provides programmatic access to call records via dedicated endpoints on an analytics host[^30]. It exposes historical and near-real-time call detail records with structured session tracking, routing context, and outcome classifications[^30][^5]. ## Endpoints and Ingestion The API publishes 2 endpoints on the host analytics-calling.webexapis.com: `GET /v1/cdr_feed` and `GET /v1/cdr_stream`[^30]. Cisco recommends `cdr_feed` for pulling records for a specific time period, while recommending `cdr_stream` as the primary API for continuously consuming records into custom reporting, analytics, or an internal data store[^30]. WarmTransfer's reading of the sources is that the 2 endpoints index records on different clocks[^9]. Specifically, this is inferred because `cdr_feed` selects records by report time (defined by Cisco as the time the call finished), whereas `cdr_stream` selects records by the time the data was inserted into the Webex Calling cloud; this accounts for Cisco's statement that the stream automatically backfills late records into subsequent calls[^9]. For `cdr_stream`, a record becomes available 1 minute after the call's data reaches the Webex Calling cloud, remains retrievable for 12 hours from the time it was stored, and returns at most 2 hours of records in a single request[^28]. For `cdr_feed`, sources disagree on the time window: the endpoint overview states that it can query any 12-hour period between 5 minutes ago and 30 days prior to the current UTC time (giving a worked example where a call ending at 9:46 AM is collectable at 9:51 AM and remains available until 9:46 AM 30 days later), whereas the `startTime` and `endTime` query parameter descriptions state that the time must be between 5 minutes ago and 48 hours ago, with `endTime` no later than 48 hours[^10][^11]. ## Authentication, Request Handling, and Pagination Retrieving Detailed Call History requires both a token carrying the `spark-admin:calling_cdr_read` scope and an authenticating user whose administrator role has Webex Calling Detailed Call History API access enabled[^26]. - **Rate Limits:** Both endpoints are rate limited to 1 initial request per minute per user token, with up to 10 additional pagination requests per minute per user token[^20]. - **Page Size:** The `max` parameter ranges from 500 to 5000, with a default of 5000; values below 500 are automatically adjusted up to 500, and values above 5000 are adjusted down to 5000[^17]. - **Location Filtering:** The `locations` query parameter accepts up to 10 comma-separated location names as shown in Control Hub[^16]. - **Regional Routing:** A request routed to a region that does not host the organization's data returns HTTP 451[^32]. Cisco states that the response body then provides endpoint information indicating where the data can be retrieved, with 4 regional hostnames published: United States and Canada, Europe, India, and Australia[^32]. Pagination is handled via a `Link` response header whose `next` relation must be followed to retrieve subsequent pages[^19]. The absence of a `next` link indicates that all records for the selected range have been returned[^19]. The `next` link includes 2 parameters not present in the caller's initial request: `startTimeForNextFetch` and `totalCount`[^19]. ## Record Schema and Call Correlation Both endpoints return 86 fields per record, matching identically in membership and ordering[^5]. Exactly 1 field description differs between the 2 endpoints: `cdr_stream` documents `RouteListCalls` as a `Failure` value for `Call outcome reason` (representing an off-net route list call blocked for exceeding the organization's Route List Calls license overage limit), whereas `cdr_feed` does not list this value[^25]. - **Session UUIDs:** Each record carries 4 session UUIDs—`Local SessionID`, `Remote SessionID`, `Final local SessionID`, and `Final remote SessionID`—described as usable for end-to-end tracking of a SIP session under RFC 7206 and draft-ietf-insipid-session-id-15[^13]. `Local SessionID` is generated by the originating user agent, `Remote SessionID` by the terminating user agent, and the final variants reflect their state at the end of the call[^13]. - **Call Leg Identifiers:** `Network call ID` identifies whether 2 records belong to the same call leg, sharing an identical value if and only if they belong to that leg[^18]. `Report ID` provides a unique identifier for an individual record to support deduplication during processing[^18]. - **Call ID Cross-References:** `Local call ID` is paired with `Remote call ID` to identify the remote record of the same call leg, and is paired with `Transfer related call ID` to identify a transferred leg[^15]. `Related call ID` contains the `Local call ID` of a separate call created due to a service activation[^22]. - **Multi-Call Interactions:** `Interaction ID` ties together multiple call patterns linked by a service interaction[^14]. In Cisco's consult-and-transfer example, when a user places an active call on hold, initiates a second call from the same app or device, and transfers the original call, both calls share the same `Interaction ID`[^14]. ## Field Values and Reporting Discrepancies - **Call Outcomes and Reasons:** `Call outcome` contains 3 values: `Success`, `Failure`, and `Refusal`[^7]. `Success` denotes a call routed and disconnected successfully, explicitly including `Normal`, `UserBusy`, and `NoAnswer`, meaning busy or unanswered calls are recorded as successful outcomes[^7]. `Failure` indicates internal or external errors, and `Refusal` denotes rejection via call block or timeout[^7]. On `cdr_feed`, `Call outcome reason` documents 26 values (3 under `Success`, 15 under `Refusal`, and 8 under `Failure`)[^6]. 2 outcome reasons explicitly reference the local gateway: `LocalGatewayLoop` (a loop detected between the local gateway and Webex Calling, categorized as `Refusal`) and `MaxConcurrentTerminatingAlertingRequestsExceeded` (simultaneous unanswered calls to a local gateway exceeding the limit for the same calling and called number, categorized as `Failure`)[^31]. - **Call Direction:** In the field, the `Direction` field is described as indicating whether a call was inbound or outbound, but it publishes the values `ORIGINATING` and `TERMINATING`[^8]. - **Answer Reason:** `Answer reason` displays `Auto Answer` when handled by the Auto-Answer feature, and `N/A` for manually answered calls, distinguishing only 1 named mechanism[^3]. - **Transfer Type:** `Transfer type` describes the type of transfer attempt, and both of its documented example values relate to AI Receptionist deflections: `AI Receptionist Deflection By Intent` (routed to a number mapped to an identified intent) and `AI Receptionist Deflection By Default` (routed to a default number after an outcome or call failure)[^29]. - **Redirect and Original Reasons:** `Redirect reason` and `Original reason` publish the same 13 values, representing reasons for the redirecting number and original called number respectively[^21]. Their descriptions differ substantively in only 1 place: `Original reason` includes `Group night forwarding` under `Unconditional`, which `Redirect reason` omits[^21]. - **Related Reason Formats:** In the field, the 33 values documented for `Related reason` include 2 malformed identifier tokens: `CalllPark` (spelled with 3 Ls) and `Remote Office` (containing a space where all other values are unspaced)[^23]. When compared to Control Hub, the Detailed Call History API returns 86 fields while the Control Hub Calling Detailed Call History Report publishes 87 columns[^4]. 3 fields account for the difference: `External customer ID` and `AI Agent ID` appear only in the Control Hub report, while `Transfer type` appears only in the API[^4]. WarmTransfer's reading of the sources is that the API documentation is incomplete when directing readers to the Control Hub report article for field references and values, as that report article omits `Transfer type`[^12]. In the field, 6 field names differ only in spelling between the API and the Control Hub report: `Client version` against `Client Version`, `Device MAC` against `Device Mac`, `Call transfer Time` against `Call transfer time`, `Final local SessionID` against `Final Local Session ID`, `Final remote SessionID` against `Final Remote Session ID`, and `PSTN Vendor Name` against `PSTN vendor name`[^27]. ## See also - See also [Webex Calling administration APIs and scopes](https://warmtransfer.net/knowledge/webex-calling-apis). - See also [What the Webex Calling detailed call history records](https://warmtransfer.net/knowledge/webex-calling-cdr-reference). - See also [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway). ## Applicability Applies to: Cisco Webex Calling. Sources checked 2026-09-15. ## What remains uncertain Sources disagree on whether the CDR Feed API retains records for 48 hours or 30 days: the overview states 30 days and the parameter descriptions specify 48 hours[^10][^11]. Whether `Transfer type` is populated on a transfer that does not involve the AI Receptionist is not covered by the sources below. Why `External customer ID` and `AI Agent ID` appear in the Control Hub report and not in the API is not covered by the sources below. How the detailed call records webhook payload relates to the 86 API fields is not covered by the sources below. What a Detailed Call History request returns when the rate limit is exceeded is not covered by the sources below. Whether the `Related reason` value is really spelled `CalllPark` in a response is not covered by the sources below. ## Sources [^1]: The Webex Calling Privacy Data Sheet states that call detail records and call logs are deleted after 23 months except in the European Economic Area countries and Switzerland where they are deleted after 13 months. Source: [Webex Calling Privacy Data Sheet](https://trustportal.cisco.com/c/dam/r/ctp/docs/privacydatasheet/collaboration/cisco-webex-calling-privacy-data-sheet.pdf), Data Deletion and Retention table, Host and Usage Information row. Checked 2026-09-16. [^2]: The calling CDR scope is documented as granting access to comprehensive Webex Calling call detail records including PII-protected phone numbers. Source: [Webex for Developers — Webex Calling API reference](https://developer.webex.com/admin/docs/api/v1/webex-calling), spark-admin:calling_cdr_read scope description. Checked 2026-09-04. [^3]: Detailed Call History Answer reason displays Auto Answer when the Auto-Answer feature handled the call and N/A for a manually answered call, so the field distinguishes only 1 named answering mechanism from everything else. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Answer reason description. Checked 2026-09-15. [^4]: The Detailed Call History API returns 86 fields while the Control Hub Calling Detailed Call History Report publishes 87 columns, and the difference is 3 names: External customer ID and AI Agent ID appear only in the report, and Transfer type appears only in the API. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema property names, compared against the 87-row Calling Detailed Call History Report column table on cisco-help-nmug598-cloud-collaboration-reports. Checked 2026-09-15. [^5]: Both Detailed Call History endpoints return 86 fields per record, and the 2 field sets are identical in membership and in order. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 application/json schema, items.items.properties, compared property by property against the same path on cisco-dev-cdr-stream-detailed-call-history. Checked 2026-09-15. [^6]: Detailed Call History Call outcome reason documents 26 values under the 3 outcomes on the cdr_feed endpoint: 3 under Success, 15 under Refusal and 8 under Failure. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Call outcome reason description, counted over the 3 grouped value lists. Checked 2026-09-15. [^7]: Detailed Call History Call outcome carries 3 values, and Success is defined as a call routed and disconnected successfully including the Normal, UserBusy and NoAnswer scenarios, so a busy or unanswered call is recorded as a successful outcome; Failure means an internal or external error and Refusal means the call was rejected because of call block or timeout. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Call outcome description. Checked 2026-09-15. [^8]: The Detailed Call History Direction field is described as recording whether the call was inbound or outbound, and the 2 values it publishes are ORIGINATING and TERMINATING (field report). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Direction description. Checked 2026-09-15. [^9]: The 2 Detailed Call History endpoints are indexed on different clocks: cdr_feed selects records by report time, which Cisco defines as the time the call finished, while cdr_stream selects them by the time the data was inserted into the Webex Calling cloud, which is why Cisco states that the stream automatically backfills late records into subsequent calls (inferred). Source: [Reports: Live Stream Detailed Call History — Get Live Stream Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-live-stream-detailed-call-history/get-live-stream-detailed-call-history), spec.parameters startTime description, against the cdr_feed startTime description on cisco-dev-cdr-feed-detailed-call-history. Checked 2026-09-15. [^10]: The overview of the Webex Calling cdr_feed endpoint states that it can query any 12-hour period between 5 minutes ago and 30 days prior to the current UTC time, and gives a worked example in which a call ending at 9:46 AM becomes collectable at 9:51 AM and remains available until 9:46 AM 30 days later (disputed). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description, retention paragraph. Checked 2026-09-15. [^11]: The startTime and endTime query parameters of the Webex Calling cdr_feed endpoint state that the specified time must be between 5 minutes ago and 48 hours ago, and that endTime should be later than startTime but no later than 48 hours (disputed). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.parameters startTime and endTime descriptions. Checked 2026-09-15. [^12]: The Detailed Call History API documentation directs a reader to the Control Hub report article for the fields it returns and their possible values, and that article does not publish 1 of the API's fields, Transfer type (inferred). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description, field reference sentence, read against the Calling Detailed Call History Report column table on cisco-help-nmug598-cloud-collaboration-reports. Checked 2026-09-15. [^13]: A Detailed Call History record carries 4 session UUIDs, Local SessionID, Remote SessionID, Final local SessionID and Final remote SessionID, described as usable for end-to-end tracking of a SIP session in compliance with RFC 7206 and draft-ietf-insipid-session-id-15; the Local value is generated by the originating user agent, the Remote value by the terminating user agent, and the 2 Final values are those values as they stood at the end of the call. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, the identical description shared by Local SessionID, Remote SessionID, Final local SessionID and Final remote SessionID. Checked 2026-09-15. [^14]: Detailed Call History Interaction ID ties together multiple call patterns linked by a service interaction, and Cisco's worked example is a consult and transfer: when a user holds an active call, places another call from the same app or device and then transfers the original call, both calls share the same Interaction ID. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Interaction ID description. Checked 2026-09-15. [^15]: Detailed Call History Local call ID is used with 2 other fields for 2 different purposes: with Remote call ID it identifies the remote record of the same call leg, and with Transfer related call ID it identifies the transferred leg. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Local call ID description. Checked 2026-09-15. [^16]: The locations query parameter on both Detailed Call History endpoints accepts up to 10 comma-separated location names as shown in Control Hub. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.parameters locations description. Checked 2026-09-15. [^17]: The max parameter on both Detailed Call History endpoints ranges from 500 to 5000, values below 500 are automatically adjusted up to 500 and values above 5000 are automatically adjusted down to 5000, and the default is 5000. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.parameters max description and schema default. Checked 2026-09-15. [^18]: Detailed Call History Network call ID shows whether 2 records belong to the same call leg: 2 records belong to the same leg if and only if they carry the same Network call ID, and Report ID is described as a unique identifier for the individual record that can be used to deduplicate while processing. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Network call ID and Report ID descriptions. Checked 2026-09-15. [^19]: Detailed Call History pagination is carried in a Link response header whose next relation must be followed to obtain the next page, the absence of a next link means every record for the selected range has been collected, and the next link carries 2 parameters the caller's own request does not: startTimeForNextFetch and totalCount. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.parameters max description, worked pagination example; spec.responses.200.headers.Link. Checked 2026-09-15. [^20]: Both Detailed Call History endpoints are rate limited to 1 initial request per minute per user token, with up to 10 additional pagination requests per minute per user token. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description, rate limit sentence; identical sentence on cisco-dev-cdr-stream-detailed-call-history. Checked 2026-09-15. [^21]: Detailed Call History Redirect reason and Original reason publish the same 13 values, Redirect reason carrying the reason for the redirecting number and Original reason the reason for the original called number, and their value descriptions differ in 4 places, of which only 1 is substantive: Original reason adds Group night forwarding to the Unconditional value and Redirect reason does not. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Redirect reason and Original reason descriptions compared line by line. Checked 2026-09-15. [^22]: Detailed Call History Related call ID names a different call that this call created because of a service activation, and its value is the Local call ID of that related call. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Related call ID description. Checked 2026-09-15. [^23]: The Detailed Call History Related reason field documents 33 named values, and 2 of them are malformed as identifiers: CalllPark is spelled with 3 letter Ls, and Remote Office carries a space where every other value is a single unspaced token (field report). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Related reason description, bulleted value list. Checked 2026-09-15. [^24]: The Control Hub Calling Detailed Call History Report publishes a Transfer type context column whose description explains that it provides additional context for the transfer type, while the report publishes no Transfer type column (field report). Source: [Reports for Your Cloud Collaboration Portfolio](https://help.webex.com/en-us/article/nmug598/Reports-for-Your-Cloud-Collaboration-Portfolio), Report templates tab, Webex Calling reports, Calling Detailed Call History Report column table, Transfer type context row. Checked 2026-09-15. [^25]: Exactly 1 field description differs between the 2 Detailed Call History endpoints: the stream endpoint lists RouteListCalls as a Failure value of Call outcome reason, describing an off-net route list call blocked for exceeding the organisation's Route List Calls licence overage limit, and the feed endpoint does not list it. Source: [Reports: Live Stream Detailed Call History — Get Live Stream Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-live-stream-detailed-call-history/get-live-stream-detailed-call-history), spec.responses.200 schema, Call outcome reason description, Failure list, compared against the same field on cisco-dev-cdr-feed-detailed-call-history. Checked 2026-09-15. [^26]: Retrieving Detailed Call History requires both a token carrying the spark-admin:calling_cdr_read scope and an authenticating user whose administrator role has Webex Calling Detailed Call History API access enabled. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description, access paragraph. Checked 2026-09-15. [^27]: 6 Detailed Call History field names are spelled differently by the API and by the Control Hub report while naming the same field: Client version against Client Version, Device MAC against Device Mac, Call transfer Time against Call transfer time, Final local SessionID against Final Local Session ID, Final remote SessionID against Final Remote Session ID, and PSTN Vendor Name against PSTN vendor name (field report). Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema property names against the Calling Detailed Call History Report column table on cisco-help-nmug598-cloud-collaboration-reports, the API spelling given first in each pair. Checked 2026-09-15. [^28]: The Webex Calling cdr_stream endpoint makes a record available 1 minute after the call's data reaches the Webex Calling cloud, keeps it retrievable for 12 hours from the time it was stored, and returns at most 2 hours of records in a single request. Source: [Reports: Live Stream Detailed Call History — Get Live Stream Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-live-stream-detailed-call-history/get-live-stream-detailed-call-history), meta.info.description, availability paragraph; corroborated by the startTime and endTime parameter descriptions. Checked 2026-09-15. [^29]: The Detailed Call History Transfer type field is described as indicating the type of the transfer attempt, and both of its documented example values are AI Receptionist deflections: AI Receptionist Deflection By Intent for a call routed to a number mapped to an identified intent, and AI Receptionist Deflection By Default for a call routed to a preconfigured default number after a conversation outcome or a call failure. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Transfer type description. Checked 2026-09-15. [^30]: The Webex Calling Detailed Call History API publishes 2 endpoints on a host of its own, analytics-calling.webexapis.com: GET /v1/cdr_feed, which Cisco recommends for pulling records for a specific time period, and GET /v1/cdr_stream, which Cisco recommends as the primary API for continuously consuming records into custom reporting, analytics or an internal data store. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description opening paragraphs, and spec.path. Checked 2026-09-15. [^31]: 2 Detailed Call History Call outcome reason values name the local gateway: LocalGatewayLoop, a loop detected between the local gateway and Webex Calling, recorded as a Refusal, and MaxConcurrentTerminatingAlertingRequestsExceeded, the number of simultaneous unanswered calls to a local gateway for the same calling and called number exceeding the limit, recorded as a Failure. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 schema, Call outcome reason description, Refusal and Failure lists. Checked 2026-09-15. [^32]: A Detailed Call History request routed to a region that does not host the organisation's data returns HTTP 451, and Cisco states that the response body then carries endpoint information indicating where the organisation's data can be retrieved; 4 regional hostnames are published, for United States and Canada, Europe, India and Australia. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), meta.info.description, closing region paragraphs. Checked 2026-09-15. [^33]: None of the 86 fields the Webex Calling Detailed Call History API returns is a media quality metric: no field name and no field description in the endpoint's schema mentions jitter, packet loss, latency, round trip time, mean opinion score or media quality. Source: [Reports: Detailed Call History — Get Detailed Call History](https://developer.webex.com/calling/docs/api/v1/reports-detailed-call-history/get-detailed-call-history), spec.responses.200 application/json schema items.items.properties, all 86 property names and descriptions searched. Checked 2026-09-16.