Your call data, your dashboards
Call Analytics Through the API
Call analytics does not have to live in someone else's dashboard. Our API exposes your call data — records within a couple of minutes of each call completing — so your own reporting stack can analyse calls alongside everything else your business measures.
- CDR data via REST
- Records within 1–2 minutes
- JSON your stack already reads
API analytics questions
What call data can the API return?
The CDR area returns call detail records for your services — the per-call data behind your reporting, appearing within about one to two minutes of a call completing. The Services area lists your active numbers; the Routing Management area controls forwarding and recording.
Do I need our own analytics platform to use it?
The API returns JSON over REST, so it feeds whatever your team already runs — a spreadsheet script, a BI tool, or an internal dashboard. What you build is up to you; the API supplies the call data, not the opinions about it.
How is this different from the built-in reporting?
The console reporting answers the everyday questions — calls per number over time — without any code. The API answers the custom ones: joining call data with your CRM records, billing systems or campaign calendars in one place.
Call analytics usually means adopting someone's dashboard and accepting its shape. There is another route: treat calls as data you own, pull it into the analytics stack you already trust, and build the views your business actually needs. Our API supports that route — this page explains what it exposes, what is realistic to build on it, and where the honest boundaries sit.
What the API exposes
Three areas, as described on the API page:
- Services — a programmatic listing of your active numbers, the inventory your analytics joins against.
- CDR (call detail records) — the per-call records that power every analytic view; records appear within roughly one to two minutes of a call completing, so dashboards stay near-current.
- Routing Management — programmatic control of forwarding and recording, which matters for analytics because it keeps your number structure consistent while your campaigns change.
The interface is RESTful JSON with bearer-token authentication, rate limited like any production API — callable from PHP, JavaScript, Python, Ruby, Go or whatever your team prefers.
What is realistic to build
The honest tier list for API-driven call analytics:
- Automated reporting. A scheduled script pulls CDRs nightly and posts calls-per-number to the channel where your team already reads numbers. The highest value per line of code.
- Joined-up attribution. Call records joined against your CRM or order data: which campaigns produced calls, and what those calls became. This is the analysis built-in dashboards cannot do for you.
- Anomaly alerting. Call volume against expectation — a number going silent is often the first sign a campaign broke.
- Custom visualisation. Dashboards in your BI tool, shaped by your fiscal calendar and team structure rather than a vendor's defaults.
Where the boundaries sit
The API returns your call data; it does not interpret it, and it does not expose other vendors' data or third-party integrations we have not built. For the everyday questions — calls per number over time — the console's built-in reporting needs no code at all, described in 1300 and 1800 number reporting. The endpoint-level detail is on the API page, and the numbers that generate the data start at $10 a month, searchable on available numbers.
Start from the endpoints
Explore the API areas
Services, CDR and Routing Management — the three areas that cover listing, records and control.