THE OPERATING MODEL
One integration.
Everything else is a switch.
You integrate once. After that, adding a capability is a call rather than a project: the same key, the same object model, the same error shape and the same invoice, whichever one you switch on.
The sandbox is open before any of it, and costs nothing.
ONCE, THEN NEVER AGAIN
The integration happens once. The rest is configuration.
Four steps, and only the first of them is engineering work.
Take a key
A test key sits on the dashboard as soon as the account exists. There is nothing to request and nobody to ask.
Build against one thing
One base URL, one authentication scheme, one object model, one error shape. Whatever you write for the first capability is what you have written for all of them.
Switch the next one on
It answers on the key you already hold and returns objects in the shape you already parse. No second base URL and no second contract.
Stop
There is no fourth step. The tenth capability costs what the second did, and that is the only claim this page makes.
Step one is the whole integration. Everything after it is a switch in an account you already have.
TRUE OF EVERYTHING
Seven things that hold for every capability
Whatever you switch on, these do not change. They are written here once rather than repeated on every capability page.
THE SHAPE
Your application, one integration
Underneath it, a layer that speaks to specialist providers so you do not have to speak to any of them.
- Your application
- Calls one REST API with one key, in whatever language you already write.
- The Telyne layer
- One object model, one authentication scheme, one event envelope, one error taxonomy, one bill.
- 3 capability areas
- Connectivity and Communications and Developer platform. An area exists when something is in it.
- Specialist providers
- Underneath, where they belong. Which one carries a given piece of traffic is our decision, not your integration.
THE SAME CALL
Three capabilities. One request shape.
Different resources, identical grammar. The noun changes and nothing else does.
# Issue a profile.
curl https://api.telyne.com/v1/esim \
-H "Authorization: Bearer sk_test_..." \
-H "Idempotency-Key: 9f2c-4a11" \
-d region="GB"Same host, same header, same idempotency key, same error shape when it goes wrong. Learning the second capability is learning a noun.
ACTIVATION
Four ways a capability comes on
Every capability arrives by one of these, and its own page says which before you build anything against it.
- Instant
- One call and it is on. Nothing to request, nobody to ask, no waiting.
- Configuration
- On once you have told us something we cannot guess: a range, a brand, a preference.
- Approval
- A short review where one is genuinely needed, such as addressing that must not collide. The request is an object you can query throughout.
- Contact us
- For the few things that are a conversation, priced and scoped rather than switched.
WHAT DOES NOT CHANGE
Consistent across every capability
This is what makes the second capability cheap, and the tenth cheaper still.
- One object model
- Nouns behave the same way. POST creates, GET reads, PATCH updates, DELETE terminates.
- One authentication scheme
- Bearer tokens, prefixed sk_test_ and sk_live_, one key per environment.
- One event envelope
- Every asynchronous thing arrives in the same shape, so a second handler is a case rather than a parser.
- One error taxonomy
- A type, a code, a message, the parameter at fault and a link. Never a bare 500.
- One bill
- Everything you activate on a single invoice, in the unit each capability meters.
ADDING ONE
A new capability arrives without breaking anything
New fields are additive, new event types are ignorable, and the version your account is pinned to does not move underneath you.
QUESTIONS
The platform in practice
What does integrating once actually get me?
One REST API, one key and one invoice across every capability in the catalogue. Adding the second capability costs a call and a case in your event handler; it does not cost another integration, another credential or another supplier relationship.
Who carries the traffic underneath?
Specialist providers, chosen by us and hidden behind one object model. Which one carries a given piece of traffic is our routing decision rather than something your integration has to know or care about.
What happens when you add a capability?
Nothing, to you. New fields are additive, new event types can be ignored by a handler that does not know them, and your account stays on the version it was pinned to at first call.
Why do some capabilities need approval?
Because a few genuinely do: addressing that must not collide, for instance. Where that is the case the capability's own page says so before you build against it, and the request is queryable throughout rather than disappearing into a queue.
Can I try it before committing to anything?
Yes. The sandbox is open before any agreement, test keys work before verification, and the integration you build there is the one you ship.
One integration, and the rest is switching things on
Join the waiting list and we will email you once, when it opens, with the capabilities that are ready first.
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.