A data usage controls API
that acts before the bill
Thresholds, caps and automatic suspension as rules on the profile, enforced by the network as usage happens rather than reported to you a month later.
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.
Write the rule. We enforce it.
Five choices. One call. The rule lives on the profile, not in your cron job.APPLIES TO
THRESHOLD
CEILING
AT THE CEILING
RESETS
rule_8Xk2vP16.0 GB — warned# The rule, as one call
POST /v1/usage-rules { "scope": "profile", "warn_pct": 80, "limit_gb": 20, "action": "suspend", "reset": "month" }
WHEN IT FIRES
The rule runs where the traffic is, not where your code is.
What happens between a device using data and a rule acting on it.
The threshold is crossed
A webhook fires with the profile, the figure and the rule that matched.
You are told, not billed later
The event arrives as it happens rather than in a monthly reconciliation.
The ceiling is reached
The action you chose is applied by the network: suspend, throttle or notify.
You decide what next
Resume, raise the ceiling, or leave it stopped. All of them are one call.
A rule that only reports is a rule that arrives after the money has gone.
WHO IT IS FOR
For anyone who has ever been surprised by a bill
Overage is not usually a pricing problem. It is a control problem: nothing stopped, because nothing was watching at the moment it mattered.
Nothing to build to be protected. Write a rule against a simulated profile today, at no cost.
WHAT YOU GET
A data usage controls API that enforces, not merely reports
Thresholds, actions and the profiles they apply to all come from the API, and every one of them fires an event you can act on.
- Scope
- One profile, a fleet, or the whole account. The same rule shape at every level.
- Thresholds
- Warn at a percentage or an absolute figure, as many times as you want before the ceiling.
- Actions
- Suspend, throttle, or notify and keep going. Applied by the network, not by your code.
- Resets
- Monthly, or never for a lifetime allowance on a device that should never exceed it.
- Events
- Webhooks on threshold reached, ceiling reached, action applied, resumed and rule changed.
- Keys
- Test and live keys are prefixed, so the two can never be confused in a log or a commit.
- Retries
- Every call that changes something takes an idempotency key. Retry without doubling a ceiling.
- Errors
- One error shape everywhere, each carrying a link to the page that explains it.
- Reference
- A published OpenAPI spec. The server validates against it and the SDKs are generated from it.
RULE 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
Rules, thresholds and events as endpoints. Put a ceiling in your own onboarding flow, and handle the webhook however your system already handles events.
# Warn at 80%, stop at the ceiling curl https://api.telyne.com/v1/usage-rules \ -H "Authorization: Bearer sk_live_4a11" \ -d '{ "profile":"esim_7Kd2xQ", "warn_pct":80, "limit_gb":20, "action":"suspend" }'
# 201 Created { "id": "rule_8Xk2vP", "action": "suspend", "limit_gb": 20, "state": "watching" }
Enforcement is not your cron job.The rule is applied by the network as usage happens, so it holds even when your service is down.
Our screens, inside your app
The control screens already built and themed to your brand: the meter approaching its ceiling, the warning, the resume button, so your customers can manage their own limit without you building a settings page for it.
A ceiling your customer can see.Showing someone their own limit before it is reached prevents more support tickets than any message sent afterwards.
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
Usage controls on Telyne
Is the ceiling enforced, or only reported?
Enforced. The action you choose is applied by the network as usage happens, which means it still holds if your own service is down at the moment the ceiling is reached.
How many thresholds can one rule have?
As many as you want before the ceiling, each as a percentage or an absolute figure. Every one of them fires a webhook carrying the profile, the figure and the rule that matched.
Can a rule apply to more than one profile?
Yes. The same rule shape applies to one profile, to a fleet, or to the whole account, so a policy written once does not have to be repeated per device.
What happens after a profile is suspended?
Nothing, until you decide. Resume it, raise the ceiling, or leave it stopped. Each is one call. Billing stops while it is suspended and the usage history stays queryable.
Is this separate from eSIM and mobile data?
No. It is a verb against a resource you already hold: the profile comes from eSIM, the allowance from mobile data, and the rule is written against either. One account, one key, one invoice.
Write a ceiling before you need one
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.