Skip to main content

Building IoT Apps with AI Coding Agents

AI coding agents like Claude Code, Codex, and OpenCode have made it dramatically faster to build custom software and IoT apps are no exception. Because Connhex exposes everything through REST APIs, it pairs naturally with AI-assisted development: your agent can query devices, read sensor data, manage rules, and handle authentication without any proprietary SDK or special glue code.

This guide walks through how to set up your agent for the best results, how to approach building a client app, how to deploy it, and a few tips worth knowing before you ship.

Frontend or backend?

This guide focuses on building client-side (frontend) apps, since that's where most custom IoT dashboards live. If you need a backend or serverless functions — for data transformation, webhooks, or business logic — everything still applies: Connhex is entirely API-driven, so your agent works the same way regardless of the runtime.

Setting up your AI agent​

You can start building immediately without any special configuration — the Connhex API reference is all your agent technically needs. That said, two MCP (Model Context Protocol) servers meaningfully improve the experience and are worth the few minutes it takes to set them up.

The Connhex MCP server gives your AI agent live, read/write access to your Connhex instance. This is particularly useful for debugging: instead of copying device IDs and channel values by hand, the agent can query your actual data in real time, inspect the schema of a model, or check the current status of a device — all without leaving the coding session.

To install it, follow the Connhex MCP server setup guide on the Connhex Dashboard. Once configured, your agent will be able to call tools like get_thing, read_channel_messages, and get_things_status directly.

Self-host

You can also self-host our open-source MCP server: here's the link to the GitHub repo.

AI models have a training cutoff, which means they can be out of date on the specifics of a given API. The Context7 MCP server solves this by fetching up-to-date documentation at query time and injecting it directly into the agent's context.

With Context7 configured, your agent will always reference the current version of the Connhex API — correct endpoint paths, up-to-date request/response shapes, and the latest features — rather than hallucinating details from an older snapshot.

Install it by following the Context7 setup instructions.

Not using MCP?

Both servers are optional. If you prefer not to install them, you can still point your agent to the Connhex API docs directly. Most agents accept a URL as context. The experience will be slightly less seamless — the agent won't have live data access and may need reminders to check the docs — but it works perfectly well.

Building your app​

With your agent configured, you can start building. A few things to keep in mind:

Describe what you want to see, not how to build it. Instead of specifying implementation details, describe your goal: "Build a dashboard that shows the current battery level of all devices registered in Connhex, refreshed every 30 seconds." Let the agent figure out which API endpoints to use and how to structure the components.

Start with authentication. Before building any UI, ask your agent to implement authentication first. Connhex supports multiple auth methods; for a deployed app on a custom domain, token authentication is the right choice. Getting this right upfront avoids having to refactor it later.

Leverage the MCP server for context. If you have the Connhex MCP server installed, you can ask your agent to inspect real data: this usually produces much more accurate code than describing the schema manually.

Iterate in small steps. Build one screen at a time, test it against Connhex, then move on. AI agents are good at incremental changes — use that to your advantage instead of asking for a complete app in a single prompt.

Deploying your app​

Once your app is working locally, deploying it is straightforward. Any major static hosting provider works well for frontend-only IoT dashboards:

  • Vercel — ideal for React, Next.js, Vue, and Svelte apps. Deploys in seconds from a Git repository and handles custom domains automatically.
  • Netlify — a great alternative with similar features; also supports form handling and identity if you need them.
  • Firebase Hosting — a good fit if you're already using Firebase for other Google Cloud services.

All three offer generous free tiers, so you can ship a first version at no cost.

Need a backend?

If your app requires serverless functions — for example, to handle webhooks, run scheduled tasks, or keep API keys off the client — all three providers support them natively (Vercel Functions, Netlify Functions, Firebase Cloud Functions). The Connhex API works identically from a serverless function as it does from the browser.

Tips and tricks​

Use token authentication for deployed apps. When your app runs on a domain other than connhex.com, use token-based authentication rather than session cookies. Tokens are stateless, work across origins without CORS issues, and can be scoped to specific resources and permissions. See the token authentication guide for setup instructions.

Use the API reference as a system prompt. If you're not using Context7, paste the relevant sections of the Connhex API docs into your agent's system prompt or project instructions. You can download the OpeAPI spec for each service through the Export button in the respective introduction page: here's the Auth service one, for example.

Keep your agent's context focused. Large IoT apps can span many API resources. Rather than describing your entire app in one session, open a new agent session for each feature and include only the relevant API section as context. Sessions with a clear, narrow scope produce significantly better code.