WarmTransfer
cdr analytics · published

The Webex Calling Detailed Call History API

Verified 2026-09-16 · 33 sources · tier 2 · 2 disputed

Also known as Detailed Call History API, Network call ID, Report ID, cdr_feed, cdr_stream.

Disputed: 2 sources below carry conflicting evidence.

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

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.

See also

Constrained by

Feeds

Related to

Referenced by

Sources

  1. 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.
    Webex Calling Privacy Data Sheet · Data Deletion and Retention table, Host and Usage Information row · Checked 2026-09-16
  2. 2
    The calling CDR scope is documented as granting access to comprehensive Webex Calling call detail records including PII-protected phone numbers.
    Webex for Developers — Webex Calling API reference · spark-admin:calling_cdr_read scope description · Checked 2026-09-04
  3. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Answer reason description · Checked 2026-09-15
  4. 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.
    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. 5
    Both Detailed Call History endpoints return 86 fields per record, and the 2 field sets are identical in membership and in order.
    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. 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.
    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. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Call outcome description · Checked 2026-09-15
  8. 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
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Direction description · Checked 2026-09-15
  9. 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
    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. 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
    Reports: Detailed Call History — Get Detailed Call History · meta.info.description, retention paragraph · Checked 2026-09-15
  11. 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
    Reports: Detailed Call History — Get Detailed Call History · spec.parameters startTime and endTime descriptions · Checked 2026-09-15
  12. 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
    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. 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.
    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. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Interaction ID description · Checked 2026-09-15
  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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Local call ID description · Checked 2026-09-15
  16. 16
    The locations query parameter on both Detailed Call History endpoints accepts up to 10 comma-separated location names as shown in Control Hub.
    Reports: Detailed Call History — Get Detailed Call History · spec.parameters locations description · Checked 2026-09-15
  17. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.parameters max description and schema default · Checked 2026-09-15
  18. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Network call ID and Report ID descriptions · Checked 2026-09-15
  19. 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.
    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
  20. 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.
    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
  21. 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
    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
  22. 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.
    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
  23. 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.
    Reports: Detailed Call History — Get Detailed Call History · meta.info.description, access paragraph · Checked 2026-09-15
  24. 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
    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
  25. 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.
    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
  26. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Transfer type description · Checked 2026-09-15
  27. 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.
    Reports: Detailed Call History — Get Detailed Call History · meta.info.description opening paragraphs, and spec.path · Checked 2026-09-15
  28. 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.
    Reports: Detailed Call History — Get Detailed Call History · spec.responses.200 schema, Call outcome reason description, Refusal and Failure lists · Checked 2026-09-15
  29. 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.
    Reports: Detailed Call History — Get Detailed Call History · meta.info.description, closing region paragraphs · Checked 2026-09-15
  30. 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.
    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

Documents

tier 2 current vendor documentation

Reports for Your Cloud Collaboration Portfolio

Cisco Systems, Inc. (Webex Help Center) · 2026-09-15 · accessed 2026-09-16

tier 2 current vendor documentation

Reports: Detailed Call History — Get Detailed Call History

Cisco Systems, Inc. (developer.webex.com) · accessed 2026-09-16

tier 2 current vendor documentation

Reports: Live Stream Detailed Call History — Get Live Stream Detailed Call History

Cisco Systems, Inc. (developer.webex.com) · accessed 2026-09-16

tier 2 current vendor documentation

Webex Calling Privacy Data Sheet

Cisco Systems, Inc. (Trust Portal) · 2025-05-01 · accessed 2026-09-16

tier 2 current vendor documentation

Webex for Developers — Webex Calling API reference

Cisco Systems, Inc. (developer.webex.com) · accessed 2026-09-16

Cite this page

APA

WarmTransfer. (2026, September 16). The Webex Calling Detailed Call History API. WarmTransfer. https://warmtransfer.net/knowledge/webex-calling-cdr

BibTeX

@misc{warmtransfer-webex-calling-cdr,
  title  = {The Webex Calling Detailed Call History API},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/webex-calling-cdr},
  note   = {Verified 2026-09-16}
}