Join the waiting listJoin
Products
Company
About TelyneWho operates the platform. White labelSell under your own brand. Who it is forSix kinds of business.
Join the waiting list Sign in Explore the platform
Home/Capabilities/Developer platform/SDKs

One telecom SDK,
every platform you build on.

Generated from the published OpenAPI specification, so a field that exists in the API exists in the client. On top of that, the whole journey as white-label screens: take all of them, take some, or take none and call the functions they sit on.

Start in the sandbox See how it works

Sandbox profiles are simulated and cost nothing. No card, no commitment.

Join the waiting list for production access

Pick the platform. The objects are identical.

Five choices. One specification underneath all of them.

PLATFORM

Node Python PHP Go Ruby Java Swift Kotlin React Native Flutter

SOURCE

Generated from OpenAPI

SCREENS

Themed to your brand Headless

ENVIRONMENT

Test Live

UPDATES

With the spec
Your appYour brand, your theming, your copy
Swiftgenerated · themed
SOURCEthe published spec
DRIFTstructurally impossible

# The client, from the specification
GET /v1/openapi.json  { "platform": "swift", "source": "openapi", "screens": "themed", "env": "test", "updates": "spec" }

WHY GENERATED

A hand-written client is a second implementation.

And a second implementation is a place for the two to disagree.

SPEC

One specification

Published, and the source of truth rather than a document written after the fact.

SERVER

The server validates against it

So the specification cannot describe an API that does not exist.

SDK

The SDKs are generated from it

So a client cannot describe an API the server does not have.

DOCS

The documentation is rendered from it

Three artefacts, one source, no drift between them.

The sandbox mocks from the same specification, which is why a sandbox call and a live call agree.

WHO IT IS FOR

For teams shipping inside an app

A mobile release cycle punishes surprises. An SDK that lags the API by a version is a bug you find in review rather than while building.

Mobile teamsSwift and Kotlin clients that match the API on the day it changes.
Cross-platform teamsReact Native and Flutter, from the same source as the native ones.
Teams shipping screensPurchase, payment and installation flows already built and themed.
Anyone who has been burnedBy a client library that quietly lagged the service behind it.
No hand-written clientGenerated from the spec
No version driftOne source for all three
No lock-inThe API is underneath
No design workScreens arrive themed

undefined Install one against the sandbox today, at no cost.

Start in the sandbox Join the waiting list

WHAT YOU GET

Clients that cannot drift from the service

What the SDK exposes is what the specification says, which is what the server enforces.

THE CAPABILITY
Platforms
Node, Python, PHP, Go, Ruby, Java, Swift, Kotlin, React Native and Flutter, all generated from the same specification.
The journey
Every screen from choosing a plan to renewing one, white-label and themed to your brand.
All optional
Any screen can be replaced by your own. The functions behind them are the API you would otherwise call directly.
Payments
Checkout hands off to your own payment service provider. Telyne does not choose it and does not sit in it.
Objects
The same objects the API returns, with the same field names, because they come from the same source.
BUILDING ON IT
Keys
The same prefixed bearer tokens. An SDK does not introduce a second credential.
Retries
Idempotency keys are set by the client for you, so a retried call returns the original response rather than issuing twice.
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.

Telyne SDKs one spec, ten clients
APISDK
API

Your screens, your way

Use both: the SDK in the app, the API on the server, without reconciling two mental models.

One specbehind every client Any languagethat speaks HTTP 
# The specification the clients come from
curl https://api.telyne.com/v1/openapi.json \
  -H "Authorization: Bearer sk_test_11a4"
# Same objects, whichever client
{ "id": "esim_7Kd2xQ", "metering": { "unit": "MB" } }

undefinedundefined

Simulated profiles, no card, no commitment. Start in the sandbox
SDK

Our screens, inside your app

The whole journey, already built: choosing, buying, provisioning, installing, and everything after it. Themed to your brand, and any of it replaceable with your own screens.

Swift · KotlinReact Native · Flutter

A journey, not a widget.Every screen a customer needs between wanting a plan and renewing one, with nothing between you and the functions underneath if you would rather build your own.

Simulated profiles, no card, no commitment. Start in the sandbox

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.

REST APIWhat every SDK call becomes. DocumentationRendered from the same spec. Test dataWhat to build the first screens against.

QUESTIONS

SDKs on Telyne

Which platforms are there?

Node, Python, PHP, Go, Ruby, Java, Swift, Kotlin, React Native and Flutter. All ten are generated from the same published specification, so they expose the same objects with the same field names.

Can the SDK fall behind the API?

Not structurally. It is generated from the specification the server validates against, so a field that exists in one exists in the other. The drift a hand-written client allows is not possible here.

Do I have to use your screens?

No. Every screen is optional and any of them can be replaced by your own, because the functions behind them are the same API you would call directly. Take the whole journey, take the parts you have not built, or take none of it.

Do the SDKs need their own credentials?

No. The same prefixed bearer tokens, test and live. An SDK does not introduce a second credential to manage.

Who handles the payment?

You do. Checkout hands off to your own payment service provider. Telyne does not choose it, does not sit inside it and does not take the transaction. You are merchant of record for what you sell; Telyne invoices you for what you consume.

Join

Install a client before you have written a screen

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.