Your first hour

Simple Telecom API: Getting Started

The Simple Telecom API gives your software control of your phone services: list your numbers, read call records, manage routing. This first-hour guide covers the shape of the API, how authentication works, and the first integration worth building.

Prefer to talk? Call 1300 858 751
  • Three areas: Services, CDR, Routing
  • RESTful JSON, bearer tokens
  • CDRs within 1–2 minutes

Getting-started questions

What can the Simple Telecom API do?

Three areas: the Services API lists your active numbers, the CDR API retrieves call detail records, and the Routing Management API controls call forwarding and recording. Together they cover reading your call data and steering your services programmatically.

How do I authenticate?

The API uses bearer-token authentication over HTTPS, with JSON responses and rate limiting as on any production interface. The authentication detail and token access are described on the API page — your account is the source for your credentials.

What should I build first?

A nightly CDR pull into your reporting stack. It is a read-only integration — no routing changes to get wrong — and it immediately answers calls-per-number questions inside the tools your team already reads.

Integrating with a phone API sounds heavier than it is, because the surface is small and honest: three areas, standard web technology, and data about calls you already own. This guide is the first hour — what the API is shaped like, how you authenticate, and the first build that produces value without risk.

The shape: three areas

The API organises everything into three areas, described on the Simple Telecom API page:

  • Services — lists your active numbers. The inventory every other integration joins against.
  • CDR — retrieves call detail records, the per-call data behind all reporting. Records appear within roughly one to two minutes of a call completing, near enough for monitoring and far beyond enough for daily reconciliation.
  • Routing Management — controls call forwarding and recording. The write side: where calls land and whether they are captured.

The technology

RESTful JSON over HTTPS, bearer-token authentication, rate limited like any production API. Nothing exotic: any language that speaks HTTP — PHP, JavaScript, Python, Ruby, Go — integrates without special tooling. The endpoint-level documentation lives on the API page; this page deliberately does not reprint it, because the canonical source should not have a fork.

The first build: a nightly CDR pull

Start with the read that cannot break anything:

  1. Authenticate with your bearer token against the CDR area.
  2. Pull the day'"'"'s call records for your services each evening.
  3. Land them in your reporting stack — a spreadsheet, a BI tool, a shared dashboard.
  4. Read calls per number over time inside the tools your team already uses.

That single loop turns call data into an ordinary business metric, and it teaches you the API's rhythms — pagination, freshness, rate limits — with no routing changes at stake. From there, the natural next steps are anomaly alerting on call volume and, eventually, routing automation; the patterns are sketched in call analytics through the API and API call routing.

What you need before any of it

The API is only as useful as the numbers feeding it. Standard 1300 and 1800 numbers start at $10 a month, tracking numbers at $5, all searchable free on available numbers. If a question about your services or credentials comes up mid-build, the direct path is contact us — the API page holds the technical detail, and the rates are on the pricing page.

Numbers come first

Get numbers worth integrating

1300 and 1800 numbers from $10 a month, tracking numbers from $5 — searchable in the live pool.