If your devices send SMS in the UK, the question is not which IoT platform to buy — it is where the message lands. There are two ways to answer that: a virtual number the device sends to, which delivers into your systems, or a hosted SIM, where the device’s SIM sits on our hardware and its inbound messages are returned to you. We carry the messages. We do not manage the devices.
That distinction is worth being blunt about, because most IoT SMS pages are written by platforms that want to sell you device management. This one is written by the people moving the message.
What we do, and what we don’t
What we do: UK virtual numbers that receive messages from devices, SIM hosting for devices that need a SIM to stay put, outbound SMS to device numbers over HTTP, SMPP or email, and delivery receipts for all of it.
What we don’t do: device fleet management, connectivity plans, dashboards, firmware, or a “platform” in the sense the IoT industry means. If a device can send or receive an SMS on a network, we are the part that carries it and gets it where it needs to go.
If that sounds narrow, it is — and it is the reason the arrangements below are cheap and predictable rather than priced per device per month.
Three arrangements and which fits
| Arrangement | How it works | Good for | The catch |
|---|---|---|---|
| Device sends to your virtual number | The device uses its own SIM and network; you hold a UK virtual number it sends to; messages arrive by webhook, SMPP or email | Devices that already have connectivity, or SIMs bought elsewhere | You need a number per logical destination, and the device must be able to dial it |
| Device SIM hosted with us | Your SIM is installed on our hosting hardware with redundant IP and power; inbound messages are forwarded to you by Auto Responder over email, HTTP or SMPP | A SIM that must stay in one stable location, or a number that already exists and must be kept | It is built for receiving: you cannot send from a hosted SIM — outbound goes through the platform |
| Platform to device | You send from our API to the device’s number, including binary payloads and concatenated messages | Commands, configuration pushes, wake-ups, alerts | The device has to be reachable, which is what the other two rows are for |
The hosted-SIM option is the one people arrive at from a different direction: they have a device with a SIM in it, the SIM is in a cupboard, and the number needs to keep working. Hosting puts it somewhere with power and a network, and forwards what arrives. It is deliberately for low-volume, non-critical traffic — for anything busier, a virtual number is the right answer and the SIM hosting page says so itself.
Why device traffic isn’t customer traffic
Four differences matter, and they change the design rather than the marketing:
- Payloads are often binary, not text. Our API takes
dataas hex anddcsset to2for 8-bit binary, instead oftxt. A binary payload is 140 bytes, which is not the same budget as 160 characters of GSM text, and it is not affected by the encoding traps that hit text templates. - Nobody replies STOP. Consent and opt-out exist because a person is on the other end. A meter is not going to unsubscribe, so the compliance weight of machine traffic is different from marketing — which is not the same as saying it has none.
- Expiry can be long. Machine messages are often sent once and wanted eventually, so we support expiry of up to seven days rather than the minutes a human-facing message lives for.
- Volume is inverted. Many devices, few messages each, spread unevenly. A queue that assumes a campaign shape — a large burst to a list — is the wrong shape for telemetry, and the rate guidance is per account, not per device.
Practical checks before you deploy
Number format. Device-originated messages arrive with the sender in E.164, so store and match on that. Outbound to a device takes the international form without the plus sign, as everywhere else in our API — sending from an application covers the format and the request itself.
Idempotency and duplicates. Devices retry, and networks occasionally deliver the same message twice. Key on the message id, and treat a repeat as a repeat rather than as a second reading.
Store and forward on the device. Coverage is not a guarantee. A device that cannot reach the network should hold the message and send it later, not drop it — and the receiving side has to tolerate a burst when signal returns.
Keep the SIM alive. If you host a pre-pay SIM, it stays in credit because you keep it in credit; we provide the power and the network, not the top-up.
Test with sim. The API simulates any send, including to a device, without spending a credit —
useful when the device in question is on a rooftop.
The honest limits
Hosting depends on IP connectivity, power and local signal. We provide redundant IP and power, but we cannot conjure a signal into a basement, and we will tell you if your site is the problem rather than the platform. Throughput on a hosted SIM is modest by design; a virtual number is the answer when a device population grows.
And nothing here replaces a device’s own logic. If the device must act on a reply, the reply has to reach something that can act — our job is to deliver it, reliably and with a receipt that says what happened.
Where to go next
M2M and IoT SMS covers binary payloads, expiry and the API options; SIM hosting is the receive-side arrangement; UK inbound SMS compares virtual numbers, short codes and hosting from the number side. For the transport itself, the developer reference has every operation and error code.
