Australian telecom, as an API
Telecom API Australia: What This One Actually Covers
Searches for a telecom API in Australia meet two very different products: sprawling communications platforms, and the narrower, honest thing we run — a RESTful API over your own 1300 and 1800 services. This page is the second kind, described plainly.
- Your services, programmatically
- Three areas, RESTful JSON
- Australian number infrastructure
Telecom API questions
What does your telecom API cover?
Your inbound services: the Services area lists your active numbers, the CDR area retrieves call detail records, and the Routing Management area controls call forwarding and recording. It is control of your own telephony, not a general-purpose voice platform.
How is this different from a CPaaS platform?
A CPaaS sells raw building blocks — programmable calls, messaging, media — and you assemble a phone system from them. Here the phone system exists: numbers, routing and reporting are managed services, and the API automates them. Less surface, far less to build.
Why does Australian infrastructure matter for an API?
Because the services it controls are Australian: numbers from the Australian numbering plan, billed in per-second increments, answered on local support hours. Integrating with your own 1300 and 1800 services is a different job from provisioning global virtual numbers.
"Telecom API Australia" is a search with two possible destinations. One is a communications platform selling raw programmable telephony — build your own phone system from blocks. The other is the thing this site actually offers: a RESTful API over Australian inbound number services, where the phone system already exists and the API automates it. This page describes the second honestly, including what it deliberately does not try to be.
What the API covers
Three areas, described in full on the API page:
- Services — a programmatic listing of your active numbers: the inventory your integrations read before they act.
- CDR — call detail records for your services, appearing within roughly one to two minutes of each call completing. The data behind every call report, available to your systems directly.
- Routing Management — control of call forwarding and recording: the write side, where your software changes where calls land and whether they are captured.
The interface is RESTful JSON over HTTPS with bearer-token authentication, rate limited for production use, callable from PHP, JavaScript, Python, Ruby, Go or any HTTP-speaking language.
The honest boundary against CPaaS
A communications platform gives you primitives and expects you to build telephony: call legs, conferencing bridges, media streams, global number provisioning. That is a real product for a real need — but it is not this. Here, the numbering-plan services are managed for you: your 1300 or 1800 number routes, records and reports whether or not you ever write code, and the API exists to automate a working system, not to assemble one. The same boundary appears in what call tracking software is — the instrument differs, so the API differs.
Why the Australian base matters
The services behind this API are Australian: numbers from the Australian numbering plan, with the caller-cost and reachability rules that follow — national reach inside the country, none outside it. If your integration needs Australian inbound numbers with per-second billing and local support hours, that is this API's home ground. If your need is global virtual numbers or outbound calling, the honest answer is that CPaaS platforms are the right search.
Getting started
The first integration worth building is a nightly CDR pull — read-only, immediately useful, described in getting started with the API. The numbers it reads start at $10 a month for standard 1300 and 1800 services, searchable on available numbers, with the full rate table on the pricing page.
Automate what you own
Get services worth automating
1300 and 1800 numbers from $10 a month, tracking from $5 — the live pool, searchable free.