A telecom REST API
that behaves the way you expect
REST over HTTPS, JSON in and out, noun-based resources and the same verbs everywhere. There is one platform and one API; everything else on it is a convenience built on top.
Sandbox profiles are simulated and cost nothing. No card, no commitment.
Pick the noun. The verbs are the same.
Five choices. One shape. /v1/esim, /v1/sims, /v1/webhooks. The structure does not change per capability.RESOURCE
VERB
PAGINATION
VERSION
FORMAT
pinned at first callcursor, not offset# The same shape, whichever noun
POST /v1/esim { "resource": "/v1/esim", "verb": "POST", "paging": "cursor", "version": "pinned", "format": "json" }
PREDICTABILITY
It should behave as expected before anyone reads anything.
The decisions that make an API guessable, and why each one was made that way.
Predictable resources
The same noun-based structure for every capability, so a second integration is not a second education.
POST, GET, PATCH, DELETE
Creates, reads, updates, terminates. There is no fifth verb hiding in a query parameter.
Cursor, not offset
Offset pagination breaks under concurrent writes, which is exactly when you are paging.
Rate limits in the headers
So a client can back off before it is refused rather than after.
None of this is clever. It is the absence of surprises, which is the useful property.
WHO IT IS FOR
For anyone who has integrated a telecom API before
The usual experience is a SOAP envelope, a portal, a spreadsheet of codes and a per-endpoint authentication quirk. This is deliberately none of those.
One API, and nothing above it can do more. Send a first call against the sandbox today, at no cost.
WHAT YOU GET
One API, and no second implementation hiding behind it
Link, Checkout and the SDKs are conveniences on top of this. None of them can do anything the API cannot.
- Transport
- REST over HTTPS, JSON in and out, with no envelope and no schema to compile.
- Resources
- Noun-based and identical per capability: POST creates, GET reads, PATCH updates, DELETE terminates.
- Pagination
- Cursor rather than offset, because offset breaks under concurrent writes.
- Rate limits
- Returned in response headers, so a client can back off before it is refused.
- Versioning
- Pinned per account at first call, with deprecation on a published timetable and warnings in headers.
- Keys
- Bearer tokens with sk_test_ and sk_live_ prefixes, one key per environment.
- Retries
- An Idempotency-Key header on every mutating call. The result is stored against it and a repeat returns the original response.
- 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.
TWO WAYS TO BUILD
Choose your pathway. Same platform either way.
Neither route is faster than the other. They differ in what arrives afterwards.
Your screens, your way
Every capability, every object and every event as endpoints. This is the platform; everything else is a shortcut to it.
# Create, with idempotency curl https://api.telyne.com/v1/esim \ -H "Authorization: Bearer sk_live_4a11" \ -H "Idempotency-Key: ord_8812" \ -d '{ "region":"europe" }'
# 201 Created { "id": "esim_7Kd2xQ" }
Nothing is hidden behind a library.Every field the finished screens use is exposed directly, and the same call returns the same object whichever route you came by.
Our screens, inside your app
A generated client in your language, from the same specification the server validates against.
undefinedThe SDKs come from the published specification, so a field that exists in the API exists in the SDK on the same day.
undefined undefined
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
REST API on Telyne
Is there anything the SDKs can do that the API cannot?
No. There is one platform and one API. Link, Checkout and the SDKs are conveniences built on top of it, which is also why a feature cannot ship to one route and be forgotten on the others.
Why cursor pagination rather than offset?
Offset pagination breaks under concurrent writes, and concurrent writes are exactly the condition you are paging under. Cursors are stable while the underlying set changes.
How do I avoid being rate limited?
Read the headers. Limits come back in the response, so a client can back off before it is refused rather than discovering the limit by hitting it.
What happens when you ship a new version?
Nothing, to you. Versions are pinned per account at first call. Deprecation runs to a published timetable with warnings in headers rather than arriving as a surprise.
What does an error look like?
One shape everywhere: a machine-readable type and code, a human-readable message, the parameter at fault and a link to the page explaining it. Never a bare 500 with a stack trace.
Make a first call before you have chosen a capability
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.