A programmable SIM card API
for the devices that still need plastic
Not every device takes a profile over the air. Order physical SIMs through the same call, provisioned before they are posted, and manage them afterwards exactly as you would an eSIM.
Sandbox profiles are simulated and cost nothing. No card, no commitment.
True of every capability
- One call switches it on. No form, no approval step.
- One key covers everything. The same credentials across the platform.
- One invoice carries all of it. Every capability on a single bill.
- The sandbox works first. Build against simulated profiles from minute one.
- One click switches it off. Billing stops the moment you do.
Order the batch. We provision before we post.
Five choices. One call. The card is live before it reaches the device.REGION
FORM
QUANTITY
PRINTING
SHIP TO
sim_b_5Nc7pR250 of 250, before dispatch# A batch of two hundred and fifty, as one call
POST /v1/sims { "region": "europe", "form": "see options", "count": 250, "print": "custom", "ship_to": "single" }
BEFORE IT SHIPS
Provisioned first, posted second.
A card that arrives inactive is a support ticket waiting to happen. These do not.
Order the batch
One request with the quantity, the form factor and where it goes.
Every card gets an identity
Each is associated with a profile and addressable by id before anything is packed.
It leaves with an id you hold
The batch is addressable from the moment it is created, not from when it arrives.
It is already known to the platform
Addressable from the moment the order was accepted, not from when somebody registers it.
The card is a delivery mechanism. The profile on it is the same object an eSIM would give you.
WHO IT IS FOR
For hardware that cannot take a profile over the air
Plenty of equipment in the field predates eSIM, sits behind a panel, or is certified against a slot. That is a reason for plastic, not a reason for a different integration.
Nothing about plastic changes the integration. Order a simulated batch today, at no cost.
WHAT YOU GET
A card is a profile that happens to be posted
Everything true of an eSIM profile is true of this one. What differs is how it reaches the device.
- Form factors
- Requested as a field on the order. Which are available is returned by the API rather than fixed on this page, because it is a property of the supply behind them.
- Provisioning
- Every card in a batch is provisioned before dispatch, so it works on insertion.
- Printing
- Your artwork on the card and the carrier, or unbranded where it will never be seen.
- Addressing
- A batch id and a per-card id, both usable from the moment the order is accepted.
- Events
- Webhooks on ordered, provisioned, dispatched, first connection and suspended.
- Keys
- Test and live keys are prefixed, so a batch can never be ordered against the wrong environment.
- Retries
- Every order takes an idempotency key. A retried request returns the original batch rather than printing a second one.
- Errors
- One shape everywhere: a type, a code, a message, the parameter at fault and a link to the page that explains it.
- Reference
- One published OpenAPI specification. The server validates against it, the SDKs are generated from it and the sandbox mocks from it.
CARD LIFECYCLE
Every state is queryable, and every transition fires a webhook.
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
Orders, batches and cards as endpoints. Put a reorder into your own stock system rather than into somebody's portal.
# Order a provisioned batch curl https://api.telyne.com/v1/sims \ -H "Authorization: Bearer sk_live_4a11" \ -H "Idempotency-Key: ord_5512" \ -d '{ "count":250, "form":"triple", "region":"europe" }'
# 201 Created { "id": "sim_b_5Nc7pR", "provisioned": 250, "cards": "/v1/sims/sim_b_5Nc7pR/cards" }
A batch is an object, not an email.It is addressable, queryable and eventful from the moment it is created, which is well before it is in anybody's hand.
Our screens, inside your app
The ordering and stock screens already built and themed to your brand, for when the people ordering cards are your customers rather than your operations team.
Stock is a number somebody has to trust.The screens read the same batch state the API returns, so what a customer is told about their order is what the platform actually holds.
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
Physical SIM on Telyne
Is a physical SIM a different integration from eSIM?
No. It is the same object with a different delivery mechanism. One key, one invoice, and the calls that suspend, resume or re-cap a profile work on a card without change.
Is a card known to the platform before it arrives?
Yes, and that is the reason to order through the API rather than a portal. A card is associated with a profile and addressable by its id from the moment the order is accepted, rather than from whenever somebody registers it.
Can I have my own artwork on them?
Yes, on the card and on the carrier, or unbranded where the card will be sealed inside a device and never seen. It is a field on the order.
How do I know which form factors I can order?
Ask the API. Availability is returned rather than published here, because it depends on the supply behind the order, and a page that lists it goes stale the moment that changes.
Is there a minimum order?
No. One card is an order. The terms do not change with volume and there is nothing to forecast before you can place one.
Order a batch before you have a device to put it in
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.