Everything you need to run connectivity.

simsonic is a connectivity and identity layer between your devices and the world's mobile networks. You buy one product, a line, and it behaves like a subscription on every carrier you need, in every country you operate, with no carrier contract of your own.

Every line gives you three things

• Reach. A multi-IMSI profile that attaches to 850+ networks and steers to the strongest one automatically.
• Control. A console and API to provision, group, suspend, bill and watch every line in real time.
• Identity. A tamper-evident Hyper ID minted at activation so a device can prove it is what it claims to be.

What happens when a line comes alive

1. You create a line and assign it a rate plan and a group.
2. The profile is provisioned to the SIM or eSIM, over the air for eSIM, pre-loaded for physical SIM.
3. The device powers on, the modem scans, and the line attaches to the best network via multi-IMSI steering.
4. A Hyper ID is issued and the first session opens. You watch it go live in Insight Tools within seconds.

The fastest route from nothing to a line carrying data. Do it in the console first; the API equivalents are shown so you can automate it later.

In the console

1. Open Lines → New line and pick the Sandbox plan so usage is free.
2. Assign a group (create one called first-test) so policy and billing stay tidy from day one.
3. For eSIM, install the QR or LPA string on the device. For physical SIM, insert it.
4. Power the device and watch Insight Tools → Live move the line from provisioning to attached.

The same thing over the API

# create a line on the sandbox plan
curl https://api.simsonic.com/v1/lines \
  -H "Authorization: Bearer $SIM_KEY" \
  -d '{ "plan": "sandbox", "group": "first-test" }'

Every account has two environments. The sandbox is for proving coverage, cost and activation with zero spend; production is the same platform with real billing and SLAs. They share one console and one API, switched by the key you use.

The recommended evaluation

1. Provision a handful of sandbox lines and put them in your real devices alongside your current SIMs.
2. Drive them through your actual routes and sites. Compare attach time, coverage and signal in Insight Tools.
3. When the numbers beat what you run today, swap the key from sk_test to sk_live. Nothing else changes.

A normal SIM holds one identity, one IMSI, tied to one operator. The moment that operator is weak or unavailable, the device is stuck. A multi-IMSI line holds several identities and can switch between them over the air, so it behaves like holding several operator subscriptions on one piece of hardware.

How steering decides

• Signal quality and the radio technology each candidate network offers.
• Cost, so the line prefers the most economical network that still meets quality.
• Policy you set, for example pinning a region to a preferred partner or avoiding a carrier entirely.

What this buys you

Resilience and reach without touching the device. If a network degrades, the line falls back to the next best IMSI automatically. When you enter a new country, the right local identity is already available, so there is no permanent-roaming risk and no SIM swap.

The radio you choose shapes battery life, coverage and what your device can do. It is the most expensive decision to reverse, because it is baked into the modem. Pick deliberately.

Rule of thumb

• NB-IoT for fixed, low-data, deep-indoor sensors that must last years on a battery: meters, parking, agriculture.
• LTE-M for things that move, need firmware updates or low-latency, and still want long battery life: trackers, wearables, alarms.
• 4G/5G for high-throughput or video: gateways, routers, cameras, kiosks.

Things people get wrong

NB-IoT does not support mobility well, so do not use it for trackers. LTE-M coverage is excellent in some countries and patchy in others, so check the map for your markets. A multi-IMSI line helps here too: it can fall back across radio types where a network supports more than one.

Roaming was designed for travellers, not for a fleet that lives in another country forever. Many operators restrict or block permanent roaming, the device gets throttled or cut off, and you find out only when units go dark in the field.

The simsonic approach

• Hold a local identity for each major market on the same line, so the device is a local subscriber, not a permanent roamer.
• Steer to that local identity automatically when the device is in-region.
• Fall back to roaming only as a safety net, never as the default.

The form factor is the physical shape of the SIM. It decides how the SIM survives in the field and how you provision it. Most IoT mistakes here come from treating an industrial device like a phone.

The options

• 2FF / 3FF / 4FF. Removable cards (mini, micro, nano). Cheap and familiar, but the slot is a point of failure under heat, shock and vibration.
• MFF2. A solderable chip rated for harsh environments and a 10+ year life. The default for industrial IoT.
• eSIM (eUICC). A reprogrammable secure element whose operator profile can be changed over the air. Usually delivered as MFF2.
• SoftSIM. No chip at all; the SIM runs in the modem or secure enclave. Saves cost and board space where the modem supports it.

Consumer eSIM (SGP.22) assumes a human with a phone tapping through menus. IoT devices have neither. SGP.32 is the GSMA standard that fixes this: it lets a server manage profiles across a whole fleet of eUICCs, no UI required.

The moving parts

• eUICC. The secure element in the device that stores one or more profiles.
• eIM (eSIM IoT Manager). The server that tells devices which profile to download, enable or switch. simsonic runs this for you.
• Profile. The operator subscription that gets downloaded over the air.

Why it matters

You can change a fleet's operator after deployment, recover devices stuck on a dead network, and ship a single hardware SKU worldwide that gets its local profile after install. No truck rolls, no SIM swaps.

An IMSI is the identifier a SIM presents to a network to authenticate the subscription. It proves the SIM is allowed on the network. It does not prove the device is the one you think it is, and it can be cloned or spoofed.

What Hyper ID adds

At activation, simsonic mints a tamper-evident identity bound to the line. The device can then cryptographically prove it is what it claims to be, to your backend and to the network, on every session.

• Bind a SIM to a specific device so a pulled SIM is useless elsewhere.
• Reject sessions from a cloned or spoofed identity before they cost you data.
• Carry a verifiable identity into your own systems for zero-trust device access.

Every line moves through a small set of states. Changing state propagates across carriers in seconds, so you control cost and security in real time, not on a billing cycle.

The states

• Provisioning → first attach in progress.
• Active → live and able to carry data.
• Suspended → billing paused, data blocked, instantly resumable.
• Retired → permanently decommissioned.

Drive it from the API

// suspend a line the moment a device is stolen
await sim.lines.update("sim_1042", {
  status: "suspended"
});
// resume just as fast when it is recovered

Managing lines one by one does not scale. Groups let you bundle lines by product, customer or region and apply policy to the whole set in one action.

What you can set on a group

• Data caps and rate plans, so a runaway device cannot generate a surprise bill.
• Allowed networks and radio types, to pin or exclude carriers.
• Alerts and webhooks on thresholds, so you hear about anomalies before the invoice does.

A practical pattern

Create one group per customer or per product line. New lines inherit the group's policy at creation, so a device is governed correctly from its very first session. Change the policy once and every line in the group follows.

Insight Tools render the exact telemetry the API exposes: live usage per line and group, full session and event logs, and radio quality per device, trended over time.

Debugging a quiet device

1. Open the line and check its last session: did it attach, and to which carrier and radio?
2. Look at signal strength over time. A device that attaches then drops is usually a coverage or antenna problem, not a SIM problem.
3. Check usage against the cap. A device that went silent may simply have hit a data cap on its group.

Pull it into your stack

# last sessions for a line
curl https://api.simsonic.com/v1/lines/sim_1042/sessions \
  -H "Authorization: Bearer $SIM_KEY"
# -> carrier, radio, bytes, started_at, ended_at

The API uses bearer tokens. Each key is scoped to an environment: sk_test for sandbox, sk_live for production. Anything you can do in the console you can do with a key, because the console calls the same API.

Your first call

# list your lines — proves the key works
curl https://api.simsonic.com/v1/lines \
  -H "Authorization: Bearer $SIM_KEY"

Polling the API for changes wastes effort and adds lag. Webhooks push events to your endpoint the moment they happen, so your systems react in real time.

Events worth subscribing to

• line.attached and line.detached — a device came online or dropped.
• usage.cap_reached — a line or group hit its data cap.
• identity.rejected — a session was refused for a failed Hyper ID check.

A handler, end to end

app.post("/hooks/simsonic", (req, res) => {
  const e = req.body;
  if (e.type === "usage.cap_reached") pauseDevice(e.line);
  res.sendStatus(200);
});

Connectors send the network's telemetry straight into your stack with no glue code to maintain. Configure a destination, choose which events to route, and simsonic delivers them with retries and a delivery log.

What you can route

• Attach, usage, session and identity events, filtered per product or customer.
• Native destinations for AWS IoT, Azure IoT Hub, Google Cloud Pub/Sub, or a generic HTTPS endpoint.
• At-least-once delivery, so you can rebuild state from the stream if your consumer was down.

Traditional plans bill each SIM its own bundle, so quiet devices waste allowance while busy ones overage. simsonic pools data across a group: every line draws from a shared allowance, and you pay for the aggregate.

Why pooling wins

• A fleet of mostly-idle sensors with a few heavy users averages out instead of overaging.
• You forecast one number for the group, not thousands of individual bundles.
• Add or retire lines without renegotiating per-SIM bundles.

Guardrails

Set a cap on the group so total spend cannot run away, and an alert below it so you hear about a trend early. Pair caps with the usage.cap_reached webhook to pause a device automatically.