Every IoT platform claims to have an API. The checkbox is always ticked. But there is a large gap between a platform that was built API-first, where the API is how the platform itself works, and a platform that bolted an API onto a closed product so it could tick the box. You only discover which one you bought when you try to do something the vendor did not anticipate.
That discovery usually comes at the worst time: mid-integration, when you need to push data into a customer’s ERP, pull it into a custom app, or wire an event to a workflow, and the API turns out to expose half of what the UI does. Now you are building workarounds around the gaps instead of building your solution.
So the real question is not “does it have an API.” It is “is the whole platform reachable through the API, cleanly, at scale.” Here is what that distinction means in practice and how to test for it before you commit.
API-first versus API-attached
An API-first platform treats the programmatic interface as the primary way to interact with the system. The dashboards, the mobile app, the vendor’s own tools all call the same API you get. That has a real consequence: if the product can do it, you can do it through the API, because that is how the product does it too.
An API-attached platform builds a closed application, then exposes a subset of functions through an API later. The tell is asymmetry. Some things you can only do in the UI, some data is not retrievable, some resources are read-only when you need to write them. Every one of those asymmetries becomes a wall for a custom integration.
TagoIO is built API-first. The REST API and SDKs are the same surface the platform uses, so device provisioning, data access, dashboards, users, and automation are all programmatically reachable. That is the property that makes non-obvious integrations possible instead of blocked.
What to actually evaluate
“Good API” is vague. Break it into the things that decide whether your integration ships.
Coverage. Can you do through the API everything you can do in the UI, including creating devices, writing and reading data, managing users and permissions, and configuring automation? Ask for the endpoint list and check it against your integration plan, not against the marketing page.
Data model access. IoT integrations live or die on getting the right data out efficiently. Check that you can query by device, by variable, by time range, and by tag, and that bulk retrieval is supported. TagoIO’s tag-based model makes this particularly clean, because you can address whole groups of devices by tag rather than iterating device by device.
Authentication and scoping. Look for tokens you can scope to specific devices or permissions, so an integration gets exactly the access it needs and no more. Account-level all-or-nothing keys are a security and blast-radius problem.
Webhooks and events, not just polling. A real integration platform pushes as well as pulls. Check for outbound webhooks and network integrations so you can trigger downstream systems on events instead of hammering the API on a timer.
SDKs and docs that match reality. An SDK in your language and documentation that reflects the current API save weeks. Test one small call against the live docs before you trust the rest.
Custom integrations this makes possible
When the API is genuinely complete, the integrations stop being special projects and become routine.
You can sync device data into an ERP or CRM so the business systems see the same reality as the operations team. You can build a custom application on top of TagoIO, using it as the IoT backend while you own the front end. You can use Analysis scripts to transform or enrich data server-side without standing up your own infrastructure. And increasingly, you can expose your data to AI assistants through the TagoIO MCP server, which is itself a clean demonstration of API-first design: the MCP server is just another client of the same API. We wrote about that layer in what MCP means for IoT.
How to test before you commit
Do not take coverage on faith. During your evaluation, pick the single hardest integration you know you will need and build a thin proof of it against a free account. Create a device via the API, write data to it, read it back filtered by tag and time, fire a webhook on an event, and pull a report. If all five work cleanly against the live docs, the API is real. If any of them require a support ticket or a UI-only step, you have found your future wall early, which is exactly when you want to find it.
An IoT platform’s API is not a feature you check off. It is the ceiling on everything custom you will ever build. Judge it by whether the whole platform is reachable, at scale, through interfaces that match their docs, and test the hardest case first. Build on API-first and your integrations are routine. Build on API-attached and every non-standard need becomes a workaround.
Want to test the API against your hardest integration? Read the docs or start free and build the proof this afternoon.
