Tracking, plus a data pipe
Call Tracking via API: The Data Layer Under the Numbers
Number-based call tracking measures calls per campaign automatically — no code needed. The API layer is for teams that want more: the same call records, read programmatically, joined with orders, tickets and campaigns in their own stack.
- Tracking first, API second
- CDRs within 1–2 minutes
- Your stack, your joins
Tracking API questions
Does call tracking require the API?
No — the tracking works without any code: a distinct number per campaign, calls logged and reported per number in the console. The API is an additional layer for teams that want the call data inside their own systems.
What call data does the API expose for tracking?
The CDR area returns call detail records for your services — which number, when, how long — within roughly one to two minutes of each call completing. JSON over REST, bearer-token authentication, callable from any HTTP-speaking language.
Can the API create or manage tracking numbers?
Numbers are provisioned through the availability pool and your account, not created via API — the API manages the services you host: listing them (Services), reading their records (CDR) and controlling forwarding and recording (Routing Management).
Call tracking has two audiences, and the pages that blur them mislead both. For most businesses, number-based tracking needs zero code: allocate a number per campaign, read the calls-per-number reports, decide the budget. For the minority with a data team, the same tracking gains a second layer — the call records read programmatically, joined into the systems where decisions actually happen. This page is for the second audience, built on the first.
The layer that needs no code
The measurement is network-side: a tracking number assigned to a campaign collects and logs its own calls — volume, durations, answered rates — and the console reports them. Nothing is installed, nothing is polled, and the attribution works from the first call. That model is described in call tracking, from $5 a month per number with call data billed per second.
The layer for data teams
The API exposes the same records to your systems:
- CDR area — call detail records per number, appearing within about one to two minutes of each call completing. Near-real-time feeds for dashboards and alerting.
- Services area — a programmatic listing of your numbers, the inventory your joins run against.
- Routing Management — write-side control of forwarding and recording, when campaign lifecycles need routing to follow.
Everything is RESTful JSON with bearer-token authentication, rate limited like any production API. The endpoint detail is on the API page, and the build sequence — feed first, control last — is mapped in telecom API integration.
What the joins look like
Three patterns cover the data-team wishlist:
- Calls joined to conversions. Call records correlated with orders or signups — which campaigns produced calls that became revenue.
- Alerting on anomalies. A campaign number going silent is an early warning; the CDR feed makes it a trigger.
- Warehouse reporting. Call records landing in your BI tool beside every other metric, on your fiscal calendar.
The first two are sketched in call analytics through the API, with the starter build in our getting-started guide.
The honest boundary
Number-based tracking is campaign-level — it tells you which number, and therefore which medium, produced the call. It does not identify keywords or ad clicks; that is session-level tooling, a different category. Within its boundary, though, the data is complete and yours — starting from numbers searchable on available numbers, with rates on the pricing page.
Start with the numbers
Tracking from $5 a month per number
Per-second call records, console reporting, and an API when your stack wants in.