Platform · Device Connectivity
Connect any device without building a backend
Connections, credentials, provisioning, an API: every IoT product needs that layer first. Thinger.io ships it, so your devices come online over the protocols they already speak.
The problem
The backend you keep rebuilding
Every connected product needs the same invisible software first, and none of it is the product.
20 pieces before the product, and one more row per protocol
- ESP32 boardsMQTT
- Linux gatewaysHTTP
- Field sensorsLoRaWAN
- Asset trackersSigfox
Thinger.io
- Connections kept alive
- Per-device credentials
- Auto-provisioning
- REST API per resource
- Live data streams
One console · one REST API
Same handling for one ESP32 on a bench or a fleet in the field
Open protocols
Speak your hardware's language
Use the protocol each device already speaks. They all end in the same device model, buckets, dashboards and API.
The native protocol
The Internet of Things Message Protocol, spoken by the open-source Thinger.io clients. One persistent connection exposes the device resources as a live REST API and carries remote OTA updates and a remote console to microcontrollers, plus remote SSH and web service proxies on Linux.
- Device API
- OTA
- Remote console
- Remote SSH
Broker included
The platform ships its own MQTT broker: point any client at it and publish or subscribe as usual. It listens on port 1883 and on 8883 with SSL/TLS, supports MQTT 3.1 and 3.1.1, and is multi-tenant by design. Topics feed buckets, dashboards and product pipelines directly.
- Ports 1883 / 8883 TLS
- MQTT 3.1 / 3.1.1
- Multi-tenant
REST for everything else
A device profile for anything that can send an HTTP POST with JSON: third-party hardware, cloud services or custom programs. Callbacks store data in buckets, trigger endpoints and update properties, and the response can carry data back for bidirectional communication.
- HTTPS POST
- JSON
- Bidirectional
Any network server
Plugins for The Things Stack, LORIOT and ChirpStack normalize each network server’s uplink and downlink JSON into one canonical schema. A product configured once keeps working when the LNS changes, with no rewritten parsers, mappings or automations.
- The Things Stack
- LORIOT
- ChirpStack
- Unified schema
The 0G network
Sigfox devices report within the network’s frame of up to 140 daily uplinks of 12 bytes. The Sigfox plugin adds auto-provisioning and payload processing for large networks, while a single device integrates in minutes through an HTTP callback.
- Uplink / downlink
- Payload processing
- Auto-provisioning
Real time on the way out
Device resources stream over WebSockets to dashboards and listeners the moment a value changes. Client and server negotiate the transmission, so a device can stream freely: data is only sent while something is listening on the other end.
- Stream on change
- Live dashboards
Developer experience
A device online in a sketch you can read
A complete ESP32 sketch with a heater relay to switch and a temperature sensor to read.
Same resources, over REST
Device API
Every resource declared in setup() appears in the console’s API explorer and becomes a REST endpoint: POST to send it a value, GET to read it.
Always connected
thing.handle() in the loop keeps the connection alive and reconnects on its own when the network drops.
Remote OTA
ESP32, ESP8266 and the other supported boards take over-the-air firmware updates from the Thinger.io VS Code extension, wherever they are deployed.
Remote console
The same connection carries a remote console session to microcontrollers, and remote SSH to Linux devices, with nothing else exposed.
ONLINE FROM THE FIRST BOOT
From one to a fleet
Provisioning that scales with production
Connecting the first device is the demo. Connecting every unit that leaves the factory is the business.
Step 01: Once, at design time
Define the product once
A product profile describes a device family: which properties it keeps, which time series buckets store its data, how payloads are parsed by scripts, and the unified API resources and dashboard template every unit inherits.
Step 02: On first connection
Units provision themselves
With auto-provisioning, devices register on first connection and receive their own identity and access token, so nobody creates units by hand. LoRaWAN fleets provision from the network server, building each identifier from a configured prefix plus the device EUI.
Step 03: At the customer
Customers onboard themselves
The claim feature moves onboarding to the end user: a link or QR code assigns devices and dashboards into their account through an automatically created workspace with predefined roles, while the developer keeps centralized control.
Client libraries
Open-source clients for the hardware you already use
Four MIT-licensed clients for Arduino, Linux, ESP-IDF and Zephyr, each in its own public repository. Anything else connects over MQTT or HTTP.
Arduino
thinger-io/Arduino-LibraryThe client in the sketch above, over WiFi, Ethernet or cellular, with OTA on supported boards.Arduino IDE · PlatformIOTargets:ESP32ESP8266Portenta H7OptaNano 33 IoTMKR NB 1500and more StableLinux
thinger-io/IOTMP-LinuxA C++20 client for gateways and edge devices, with a remote terminal, TCP proxy and OTA updates built in.CMake · OpenSSL · Boost.AsioTargets:Raspberry PiDebianUbuntuFedoraOpenWrt StableESP-IDF
thinger-io/IOTMP-ESPIDFA native ESP-IDF component that runs the client in its own FreeRTOS task, over TLS by default.ESP-IDF 5.x and 6.xTargets:ESP32ESP32-S3ESP32-C3 PreviewZephyr
thinger-io/IOTMP-ZephyrA Zephyr RTOS module with a dedicated client thread, set up through Kconfig, with TLS over mbedTLS.West module · KconfigTargets:nRF52840STM32 F767ZIESP32-C3 Preview
The ESP-IDF and Zephyr clients share IOTMP-Embedded, a portable header-only C++ core, and the protocol itself is open at iotmp.io. Hardware without a client connects over MQTT or HTTP.
Good to know
Frequently asked questions
What engineers ask before connecting their first fleet.
Do I need to run my own MQTT broker?
No. The platform includes its own MQTT broker, so any MQTT client can connect directly with its device identifier and credentials. It listens on port 1883 and on port 8883 with SSL/TLS, supports MQTT 3.1 and 3.1.1, and is multi-tenant by design, so several organisations share a broker without overlapping topics. Topics can feed data buckets, dashboards and product pipelines directly.
What is IOTMP and when should I use it?
IOTMP, the Internet of Things Message Protocol, is the platform’s native protocol, implemented by the open-source clients for Arduino, Linux, ESP-IDF and Zephyr. A device connected over IOTMP keeps one persistent connection through which its resources are exposed as a live REST API, and gains features plain telemetry protocols do not carry: over-the-air firmware updates and a remote console on microcontrollers, plus remote SSH, socket proxies and remote web services on Linux devices. If your hardware can run one of the clients, IOTMP is the recommended way to connect it.
How are devices provisioned at scale?
Through products. A product profile describes a device family once: its properties, buckets, payload scripts, API resources and dashboard template. With auto-provisioning enabled, units register themselves on first connection and receive their own identity and access token instead of being created by hand. LoRaWAN fleets provision from the network server side, building each device identifier from a configured prefix plus the device EUI, and the claim feature lets end customers onboard their own units with a link or a QR code.
How is device communication secured?
Each device authenticates with its own identifier and credentials, and credentials are stored hashed with PBKDF2 SHA256 and a 32-byte salt, never in plain text. IOTMP clients connect over TLS, MQTT clients can use SSL/TLS on port 8883, and HTTP devices call their callback over HTTPS with an authorization token. The platform is operated under an ISO 27001 certified management system.
Can I integrate hardware that cannot run a Thinger.io client?
Yes. The HTTP device profile integrates anything able to send an HTTP POST with a JSON body: third-party hardware, cloud services or custom programs. Callbacks can store the data in buckets, trigger endpoints and update device properties, and the HTTP response can carry a property back to the device for bidirectional communication. Sigfox devices integrate the same way through callbacks or through the Sigfox plugin, and LoRaWAN devices connect through their network server with the corresponding plugin.
Connect your first device today
Create a free developer account and bring a device online with the protocols and libraries above, or read the documentation first. When the product grows, the platform grows with it.