Standard, by design
Telecom API Authentication: Bearer Tokens, Plainly
The Simple Telecom API uses bearer-token authentication over HTTPS: your secret token rides in the Authorization header, the server verifies it, and your integration speaks ordinary HTTP. Here is how the pattern works and how to keep tokens safe.
- Bearer tokens over HTTPS
- Standard HTTP, any language
- Rate-limited production API
Authentication questions
How does the API authenticate requests?
Bearer-token authentication over HTTPS: you include your secret token in the Authorization header of each request, and the server verifies it before responding with JSON. It is the standard HTTP pattern used across the industry.
Where do I get a token?
From your account with us — the API page describes access, and the credentials are tied to your services. Tokens are secret material: they belong in your server's configuration or secrets store, never in client-side code or repositories.
What happens if a request is unauthenticated or excessive?
Requests without valid authentication are rejected, and the API is rate limited like any production interface — so build your integration to handle both rejections gracefully: back off, retry, and alert a human if rejections persist.
Authentication is the first thing any integration touches, and the best kind is the kind that surprises nobody: the Simple Telecom API uses bearer-token authentication over HTTPS — a secret token in the Authorization header, verified on every request. This page explains the pattern, how to handle your token, and the failure modes a well-built integration expects.
The pattern
Every request your integration makes carries the same header:
- Authorization: Bearer <your-token> — sent over HTTPS, so the token is encrypted in transit.
- JSON in, JSON out — the API speaks RESTful HTTP, callable from PHP, JavaScript, Python, Ruby, Go or anything with an HTTP client.
- Rate limiting — production APIs limit request rates, and this one is no exception: build in backoff and retry rather than assuming unlimited throughput.
The endpoint-level documentation — which headers, which paths — is on the API page, which is the canonical source this page deliberately does not fork.
Handling the token
A bearer token is the keys to your phone services — whoever holds it can read call records and change routing. The handling rules are short and standard:
- Keep it server-side. Tokens belong in server configuration or a secrets store — never in browser code, mobile apps, or anywhere a view-source reveals them.
- Never commit it. Repositories outlive projects; a token in git history is a token exposed.
- Rotate on suspicion. If a token may have leaked, treat it as compromised and get it replaced — the direct path is contact us.
The failure modes to expect
A production integration should expect three responses and handle them gracefully:
- 401-class rejections for missing or invalid tokens — alert a human, because this usually means a configuration mistake rather than a transient fault.
- Rate-limit responses — back off and retry with spacing; do not hammer.
- Occasional network failures — retry idempotent reads freely; treat write operations (routing changes) with confirmation steps.
The data your token protects is worth the care: call detail records appearing within a couple of minutes of each call, described in call detail records via API, and routing control walked through in API call routing.
Getting credentials
Authentication follows services: numbers hosted with us — standard 1300 and 1800 from $10 a month, tracking from $5, searchable on available numbers — come with API access as described on the API page. Rates on the pricing page.
Credentials follow services
Get numbers worth integrating
1300 and 1800 numbers from $10 a month, tracking from $5 — the live pool, searchable free.