Telecom API documentation
that cannot describe the wrong API
The documentation is rendered from the published OpenAPI specification, the same one the server validates against, the SDKs are generated from and the sandbox mocks from. One specification, no drift.
Sandbox profiles are simulated and cost nothing. No card, no commitment.
WHY IT STAYS TRUE
Documentation goes stale because it is written twice.
Once in the code and once in a document, and then only one of them is maintained.
The specification changes
It is the source of truth, not a description produced afterwards.
The server follows it
It validates against the specification, so the API cannot quietly differ.
The pages are re-rendered
From that same specification, which is why they describe what exists.
So do the SDKs and the sandbox
Four artefacts, one source. Drift is not a discipline problem here; it is impossible.
Prose still has to be written by someone. What cannot be wrong is the reference.
WHO IT IS FOR
For everyone who has followed documentation into a wall
The parameter that no longer exists, the endpoint that was renamed, the example that returns a 400. Every one of those is the same failure: two sources.
The reference is generated. The prose is written. Read the specification directly today, at no cost.
WHAT YOU GET
A reference that is the same artefact the server obeys
What is documented is what is specified, and what is specified is what is enforced.
- Source
- One published OpenAPI specification, versioned, and available as an endpoint rather than a download.
- Reference
- Every endpoint, field and type rendered from it, so a documented field is a field that exists.
- Examples
- Drawn from the specification, which is why an example does not return a 400.
- Errors
- Every error code has a page, and every error response carries a link to it.
- Versioning
- Documented per version, matching the version your account is pinned to.
- Keys
- The prefixes are documented where they are used, rather than in a security page nobody reaches.
- Retries
- Idempotency is documented on every mutating call, because it applies to every mutating call.
- Errors
- One shape everywhere: a type, a code, a message, the parameter at fault and a link. Never a bare 500 with a stack trace.
- Reference
- One published OpenAPI specification. The server validates against it, the SDKs are generated from it and the sandbox mocks from it.
WORKS WITH
Switch on the next one the same way
Nothing new to sign and nothing new to integrate. The same call with a different noun.
QUESTIONS
Documentation on Telyne
How is the documentation kept current?
It is rendered from the published OpenAPI specification, which the server validates against. It is not maintained alongside the API; it is produced from the same artefact the API obeys.
Can I get the specification itself?
Yes. It is an endpoint rather than a download, so tooling can consume it directly, generate a client from it, or diff it between versions.
Why do examples in other APIs stop working?
Because they were written by hand next to a service that moved. Rendering them from the specification removes the second source that made that possible.
Is there a page for each error?
Yes, and every error response carries a link to it in the payload. The error shape includes a docs field for exactly that reason.
Which version am I reading?
The one your account is pinned to, since versions are pinned per account at first call. Deprecation runs to a published timetable rather than arriving unannounced.
Read the specification before you write a line
No approval step and nothing to sign. The sandbox is open now, and production access opens in the order requests arrive.
One email at launch. Nothing else, and unsubscribe in one click.
We send a link to confirm the address. Unconfirmed addresses are deleted after 30 days.
Complex requirement or an existing estate to move? Talk to us.