Read account call records

Retrieve account call records

Read inbound or outbound call records for your API account. These records contain private calling and billing information. Keep them in authorized server-side workflows and avoid unnecessary logging or sharing.

This legacy endpoint currently has a fixed default date window and no pagination. Use the portal’s call-history/export workflow when you need a different reporting period or large historical exports; custom date parameters in this endpoint are not reliable.

Requests

Authenticate over HTTPS using your enabled API account from its allowed source IP address. The example uses credentials in environment variables. No body is needed for the supported default-window requests.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  https://api.multitel.net/v3/cdrs

Call-record request paths
Path	Scope
/v3/cdrs	Account inbound records in the default date window.
/v3/cdrs/{number}	Inbound records whose number exactly matches the supplied number. Prefer the full digits used in your inventory.
/v3/cdrs/all/outbound	Account outbound records in the default date window. The outbound branch ignores the first path argument; all is a placeholder here, not an inbound wildcard.

Use the exact inbound or outbound direction shown above. The outbound branch does not implement a per-number filter. Adding a number to that path does not narrow the outbound results.

Default reporting window

The query starts at midnight on the server calendar date 30 days before today and ends at midnight at the start of today. It therefore does not include the rest of the current day. This is not a rolling 720-hour window ending at the current time.

The current implementation does not reliably support date_from/date_to form fields: supplying custom dates leaves its partition-year variables unset. Do not use those fields for a production report. Query-string dates and pagination parameters are not implemented as alternatives.

Response

Illustrative selected inbound fields only; this is fictional data and not the complete returned record.

{
  "status": {
    "code": "200",
    "msg": "",
    "results": 1
  },
  "response": [
    {
      "number": "12025550123",
      "callerid": "12025550124",
      "disposition": "ANSWERED",
      "billseconds": "60",
      "billcost": "0.0100",
      "callsid": "11111111111111111111111111111111",
      "date_created": "2026-10-01 12:00:00 UTC"
    }
  ]
}

response is a list. The shared response envelope can include status.results as its row count. Result codes can be strings. A no-records result uses API code 404 with a No entries found message instead of a successful empty list.

Record fields

Principal returned fields
Fields	Meaning
number, callerid	Inbound number and caller identifier for the inbound projection.
calling, called, callerid	Calling/called identifiers for the outbound projection. Do not infer a verified subscriber identity from caller ID.
disposition, billseconds, billcost	Stored call disposition, billed duration and stored billing amount. Values can use legacy database string formats.
callsid	The stored call UUID for correlation.
date_created	A date/time string with a literal UTC suffix, rather than a guaranteed ISO8601 timestamp. Parse the returned format explicitly.
Other fields	Inbound records also include failure/cost/channel/quality/origin diagnostics; outbound records include termination-region diagnostics. The full response can include infrastructure information and should be treated as private.

The endpoint adds no explicit ordering or pagination. Do not assume newest-first results, a stable row order or an incremental synchronization cursor. The returned billing fields are stored call records, not a quotation for a future call.

Errors and reporting limits

Read both HTTP status and JSON status.code/status.msg. No entries in the selected account/window returns API code 404. Authentication and source-IP restrictions also apply. A large unpaginated report or an unreliable custom-date request can fail; repeated full-table polling is not an incremental export strategy.

The reviewed handler contains read queries and no account debit or call initiation. A returned record does not prove that a person answered; interpret the stored disposition and duration for your reporting use case.