Skip to content
Thirdlane

CDR

The CDR section lets you select and view Call Detail Records - one row for every call the system handled, capturing who called whom, when, for how long, and how the call ended. CDR is the authoritative record for answering everyday questions like “did this call connect?”, “how long did it last?”, and “what number did it come from?”, and it is the raw data behind billing reconciliation, dispute resolution, and traffic analysis.

Organization Analytics CDR

Reports > Call Detail Records (new) opens the analytics CDR page (/reports/cdr.html): search and page through calls, then open a Call Detail story (legs, queue steps, IVR, hunt, recording links). The classic Configuration Manager CDR grid remains available as Call Detail Records (classic).

For summarized traffic and charts for one organization, use Organization Analytics.

You can specify a selection filter to narrow what is shown. You can filter by various fields, including a range of dates, caller id, and source and destination channels.

Thirdlane stores tenant name in “userfield“ database table column and limits queries that users can run to the tenants the users are allowed to manage.

Clicking on >> toolbar button shows additional CDR fields, clicking “Export to CSV” allows you to download the entire CDR in CSV format.

Clicking on “Recording(s)” opens a window where you can listen to the call recording associated with the CDR record.

Running queries against a large CDR creates high load on the server, so we strongly recommend minimizing CDR record retention with “Keep CDR records for” in Tenant or system-wide Preferences where you can also specify “Maximum date range” to limit the date range allowed in records selection in Configuration Manager. We recommend moving any reporting to a different database or a separate server.

Importing CDR via the REST API

Historical call records from another system can be imported in bulk so they appear here alongside live records. Because CDR volumes can be large, the import runs as an asynchronous job: upload a CSV (recommended) or an inline records array, then poll the job for progress.

Terminal window
# Preview first - counts what would be created, writes nothing
curl "https://pbx.example.com/api/tenants/acme/cdr/import" \
  -X POST -H "X-API-Key: $TL_KEY" -F "[email protected]" -F "dry_run=1"


# Real import returns a job_id you poll with GET .../cdr/import/{job}
curl "https://pbx.example.com/api/tenants/acme/cdr/import" \
  -X POST -H "X-API-Key: $TL_KEY" -F "[email protected]"

The CSV must include a uniqueid column (used to skip already-imported rows) and one of calldate_epoch (preferred) or calldate. The tenant is applied automatically - do not put it in userfield. Import call recordings before the CDR that reference them. See the Data Migration and Import guide for the full workflow.

Best practices

  • Always filter by a date range first. A narrow window returns results quickly and avoids straining the server; broad, unfiltered queries over a large CDR are the most common cause of slow reports.
  • Set retention to match your needs. Keep records only as long as billing, compliance, or troubleshooting require - shorter retention keeps queries fast and disk usage low.
  • Offload heavy reporting. For recurring analytics, export to CSV or replicate CDR to a separate reporting database or server rather than repeatedly querying the live system.
  • Use CDR Reports for trends, CDR for individual calls. When you want traffic patterns rather than a specific call, CDR Reports summarize the same data by hour, day, and month.