Picking an IoT platform for custom integrations comes down to one question: can you pull your own data out and push commands back in through an API you control, or are you stuck exporting CSVs from someone else's dashboard? This guide compares five platforms on API surface, protocol support, and how much a systems integrator can actually build on top of them in 2026.
- The best IoT platform for custom integrations and open APIs depends on your protocol mix: mixed LoRaWAN, mioty and MQTT sites fit the Kilo IoT Platform's built-in network server and REST/gRPC API.
- AWS IoT Core and Azure IoT Hub extend furthest when you're already running production workloads inside that cloud account.
- ThingsBoard's open-source Community Edition is the only option here you can self-host and modify at the source level.
- Losant fits teams building a customer-facing IoT product, not an internal operations dashboard.
- Every platform on this list supports MQTT in 2026; the real differences are rules engines, access control and native LoRaWAN/mioty support.
What makes an IoT platform good for custom integrations and open APIs
A platform earns a spot on this list because of what it exposes, not how it looks. Six things matter for anyone building custom integrations in 2026:
- Protocol breadth — native MQTT plus LoRaWAN and/or mioty support, without bolting on a second network server
- Open API surface — REST and/or gRPC endpoints, not just a proprietary CSV export
- A rules engine you can version and roll back, not a black box that changes behavior with no history
- Access control fine enough for a single scoped integration key, so one broken script can't touch every tenant
- Deployment flexibility — managed cloud, or self-hosted/on-premise if compliance requires it
- Bidirectional device commands — can it push configuration or control changes back down, or only ingest readings
Why does an IoT platform need an open API instead of just a dashboard?
MQTT is an OASIS standard, which is why almost every platform in this space speaks it — the protocol layer stopped being the differentiator years ago. LoRaWAN is maintained by the LoRa Alliance and mioty is standardized under ETSI TS 103 357, so a platform's real job is turning either radio protocol into something a systems integrator, DevOps engineer, or facilities engineer can query without learning gateway firmware.
The failure modes are predictable: vendor lock-in when the only export path is a manual report, webhook timeouts when a rules engine can't retry, and schema drift when device firmware changes and nobody flags it in the API contract. An open API with scoped keys and a rules engine you can test before deploying avoids most of that. The Kilo IoT Platform was built around that requirement — REST and gRPC endpoints, scoped keys, and ABAC access control instead of one shared admin login.
Best IoT platforms for custom integrations and open APIs, compared
| Platform | Best for | API/protocol surface | Rules/automation | Deployment |
|---|---|---|---|---|
| Kilo IoT Platform | Mixed LoRaWAN, mioty, MQTT sites | REST, gRPC, MQTT connector, native LoRaWAN/mioty network server | Visual BPMN rules with CEL expressions, version control, rollback | Managed cloud or on-premise |
| AWS IoT Core | AWS-native engineering teams | REST, MQTT, IoT Core for LoRaWAN | Rules Engine (SQL-like) routing to Lambda/S3/Kinesis | Managed (AWS account) |
| Azure IoT Hub | Microsoft-standardized enterprises | REST, MQTT, AMQP, device twins | IoT Edge modules, Azure Digital Twins (separate service) | Managed (Azure account) |
| ThingsBoard | Self-hosted, source-level customization | REST, MQTT, CoAP, HTTP | Visual rule chains, extensible with custom nodes | Self-hosted (open source) or managed Professional Edition |
| Losant | Customer-facing IoT products | REST, MQTT, CoAP | Low-code visual workflow engine | Managed cloud |
1. Kilo IoT Platform: best for mixed LoRaWAN, mioty and MQTT integrations
Kilo runs a built-in LoRaWAN and mioty network server, so LoRaWAN and mioty devices land in the same platform as anything publishing over MQTT — a PLC, an energy meter, or a BMS connector. Everything comes out through the same REST and gRPC API, scoped with per-key permissions and ABAC access control, with an immutable audit trail behind it.
Kilo IoT Platform pros:
- REST and gRPC APIs with scoped keys mean a single integration key can be limited to one dashboard's worth of data, not the whole tenant
- Built-in LoRaWAN and mioty network server skips a separate network-server integration step other platforms require
- Visual rules engine (BPMN with CEL expressions) ships version control, one-click rollback, and step-through debugging against a test payload before it goes live
- A built-in AI assistant can onboard devices, write rules, and set alarms from plain-language requests, scoped to the signed-in user's permissions and confirming before consequential changes
Kilo IoT Platform cons:
- Hardware comes through Kilo Electronics' partner catalog rather than an in-house sensor lineup, so device sourcing is a separate step
- BPMN plus CEL expressions takes longer to pick up than a plain if-this-then-that rule builder if your team hasn't touched either before
- On-premise deployment and gRPC access are built for integrators and system builders, not a single-sensor hobby setup
Best for: teams running mixed LoRaWAN, mioty, and MQTT devices who want one API surface instead of three, and an AI assistant that can build rules instead of writing CEL by hand.
See the API on your own devices
Check REST, gRPC and MQTT connectivity against your current sensor mix.
2. AWS IoT Core: best for teams already building inside AWS
AWS IoT Core is a managed MQTT broker and device gateway with Device Shadows for last-known-state queries, and its Rules Engine routes messages into Lambda, S3, DynamoDB or Kinesis. IoT Core for LoRaWAN extends the same account to LoRaWAN gateways.
AWS IoT Core pros:
- Native integration with the rest of AWS if your production stack is already there
- Device Shadows give a queryable state model even when a device is offline
- IoT Core for LoRaWAN keeps LoRaWAN devices inside the same account and IAM boundary
AWS IoT Core cons:
- The Rules Engine's SQL-like syntax and IAM policies add a learning curve for teams outside the AWS ecosystem
- No native mioty support — mioty devices need a separate network server bridged in over MQTT
- Billing spans multiple services (IoT Core, Lambda invocations, storage), so cost tracking means watching more than one line item
Best for: engineering teams already running production workloads on AWS who want the IoT layer inside the same account and access controls.
3. Azure IoT Hub: best for Microsoft-standardized enterprises
Azure IoT Hub handles MQTT, AMQP and HTTPS ingestion with device twins for desired-versus-reported state, and IoT Edge pushes compute and rules down to the gateway itself. Azure Digital Twins adds a spatial graph on top, but it's a separate service you wire in.
Azure IoT Hub pros:
- Device twins model desired vs. reported state per device out of the box
- IoT Edge runs container workloads and rules locally on the gateway, not just in the cloud
- Azure Digital Twins layers a spatial building model on top for facilities-scale projects
Azure IoT Hub cons:
- LoRaWAN and mioty aren't native — both need a third-party network server integrated through IoT Hub's endpoint
- Azure Digital Twins is a separate product from IoT Hub, so a full picture means wiring two services together
- Enterprise-tier throughput units are sized for fleets in the thousands, not a five-device pilot
Best for: organizations standardized on Microsoft's cloud that need device twins and edge compute inside Azure Resource Manager.
4. ThingsBoard: best for source-level customization and self-hosting
ThingsBoard is an open-source (Apache 2.0) IoT platform with MQTT, CoAP and HTTP transports and a visual rule chain engine. A paid Professional Edition adds multi-tenant and white-label features on top of the free Community Edition.
ThingsBoard pros:
- Community Edition is free to self-host and fully forkable at the source level
- Rule chain engine is visual and extensible with custom nodes
- Multi-tenant and white-label options exist for teams that outgrow the community tier
ThingsBoard cons:
- Community Edition lacks the fine-grained access control and immutable audit trail found in paid tiers
- Self-hosting means you own upgrades, scaling and uptime — there's no managed fallback on the free tier
- No built-in LoRaWAN or mioty network server; both need a separate server bridged in over MQTT
Best for: teams with the engineering capacity to self-host and who want to modify the platform's source directly.
5. Losant: best for customer-facing IoT products
Losant is a low-code IoT application platform built around a visual workflow engine, with device management and dashboards aimed at product teams shipping a customer-facing app rather than an internal ops dashboard.
Losant pros:
- Workflow engine handles device logic and application logic on one visual canvas
- Experience Studio builds customer-facing app pages without a separate front-end stack
- Supports MQTT, CoAP and REST-based device connections
Losant cons:
- Complex logic spread across many linked workflows gets harder to trace than a code-first rules engine
- LoRaWAN and mioty require an external network server bridged in over MQTT, same limitation as Azure IoT Hub and AWS IoT Core
- White-label and enterprise features need a direct sales conversation rather than self-serve setup
Best for: product teams building a customer-facing IoT application, not an internal facilities dashboard.
How were these IoT platforms evaluated for custom integrations?
Each platform was checked against the six criteria above: protocol breadth, open API surface, a versionable rules engine, scoped access control, deployment flexibility, and bidirectional device commands. None of the five wins on every axis — that's the point of ranking them by use case instead of a single score. Integrating sensor data with your own dashboard via API looks different depending on whether your data source speaks MQTT natively or needs a bridge, so protocol fit gets weighted heavily.
Which IoT platform should you choose for custom integrations?
If you don't already know: start with the protocols running on your sites, not the vendor name. LoRaWAN and mioty devices mixed with MQTT-speaking equipment point toward a platform with a built-in multi-protocol network server and an open API layer — that's the gap the Kilo IoT Platform was built to close, including guidance on securing MQTT connections for industrial IoT deployments. Pure MQTT/cloud stacks point toward AWS IoT Core or Azure IoT Hub, depending on which cloud account already runs your workloads. Teams who need to modify the platform's source code, or who have a compliance mandate against managed services, default to ThingsBoard's Community Edition. Teams building a product other people log into, rather than an internal ops view, fit Losant.
FAQ
What is the best IoT platform for custom integrations and open APIs in 2026?
It depends on your protocol mix. Sites running LoRaWAN, mioty and MQTT devices together get the most out of a platform with a native multi-protocol network server and a REST/gRPC API, such as the Kilo IoT Platform; AWS-native or Azure-native teams typically extend AWS IoT Core or Azure IoT Hub instead.
Does AWS IoT Core have an open API for custom integrations?
Yes, AWS IoT Core exposes REST and MQTT interfaces along with a Rules Engine that routes messages into Lambda, S3, DynamoDB or Kinesis. It works best when your other production workloads already run inside the same AWS account.
Is ThingsBoard good for building custom IoT integrations?
ThingsBoard's open-source Community Edition is a strong fit if you want to self-host and modify the platform at the source level. It lacks the fine-grained access control and audit trail of paid tiers, and self-hosting means you own uptime and patching.
What API type matters most for IoT integrations, REST or MQTT?
Both matter for different jobs. MQTT (an OASIS standard) handles the constant stream of device-to-cloud data, while REST or gRPC APIs handle pulling that data into your own dashboard, app, or BI tool on demand.
Can I self-host an IoT platform instead of using a managed cloud service?
Yes. ThingsBoard's Community Edition is fully self-hostable and open source, and the Kilo IoT Platform also offers on-premise deployment for teams that need it. Self-hosting shifts uptime and scaling responsibility onto your own team.
How does Kilo's API differ from a typical IoT dashboard tool?
Kilo exposes REST and gRPC endpoints with scoped API keys and ABAC access control, plus an immutable audit trail, rather than a single admin login with a CSV export button. It also runs a built-in LoRaWAN and mioty network server, so those protocols don't need a separate integration.
Do open-source IoT platforms support LoRaWAN and mioty out of the box?
Not natively in most cases. ThingsBoard, for example, needs a separate LoRaWAN or mioty network server bridged in over MQTT, which adds an integration step that a platform with a built-in network server avoids.
What's the difference between a device API and a rules engine API?
A device API handles reading and writing device data and commands. A rules engine API (or its interface) lets you version, test and deploy the automation logic that reacts to that data, such as firing an alarm when a threshold is crossed.
What most teams miss when picking an API-first IoT platform
Most evaluations stop at "does it have a REST API" and skip the access control question entirely. A platform that hands out one shared API key for the whole tenant turns every integration into a blast-radius problem — one broken script and every dashboard, alarm, and downstream system sees it. Scoped keys with ABAC-style permissions, paired with an audit trail that shows which key touched what, matter more in 2026 than which HTTP verbs are supported.
