Building White-Labeled Companion Apps for Connected Products

End users expect a polished branded app to come with their connected device. Not a generic IoT dashboard, but a purpose-built experience that reflects the product's identity and gives users the controls that matter for their specific use case.

User authentication, device association, real-time data feeds, push notifications, permission management: the same requirements appear whether you're shipping a thermostat app, a pool controller app, or an industrial monitoring app.

The challenge​

The visible part of a companion app, the UI, is only a fraction of the work. For every feature a user sees, there is a backend requirement:

• User accounts and authentication: registration, login, password reset, OAuth, multi-factor authentication. Each platform (iOS, Android, web) needs the same backend behavior.
• Device ownership: a user needs to claim ownership of their device after purchase, and that ownership association must be enforced at the API level, not just in the UI.
• Multi-app architecture: a manufacturer with multiple product lines needs separate branded apps, but maintaining separate backends for each is expensive. A shared backend with per-app data isolation is the right model, and building that isolation correctly is non-trivial.
• Real-time data: home automation and monitoring apps require low-latency data feeds; polling is not sufficient for a good user experience.
• Push notifications: delivery across iOS and Android, with per-user preferences and delivery tracking.
• Access control: an installer should see different data than an end user; a reseller should see different data than a manufacturer's internal team.
• White-labeling: each app has its own branding, feature set, and domain, but they all run on the same backend infrastructure.

What it takes to get it right​

A backend designed for white-labeled IoT companion apps needs:

1. API-first design, a well-documented REST and WebSocket API that any frontend team can build against, regardless of the framework or platform.
2. Multi-app isolation, multiple apps share the same infrastructure but see only their own data; cross-contamination is impossible at the data model level.
3. Device ownership model, a formal concept of which user or organization "owns" which device, enforced at the API level, with configurable transfer and sharing semantics.
4. Real-time events, WebSocket or MQTT subscription to device telemetry, so the app UI updates without polling.
5. White-label notification delivery, push notifications sent from your app's sender identity, not a generic IoT platform.

How Connhex solves it​

Connhex Cloud provides the REST and WebSocket API layer. Every capability (telemetry ingestion, device control, user management, subscriptions) is exposed as an API that your frontend team calls to build fully custom branded interfaces.

Connhex Auth handles user identity: registration, login, OAuth flows, session management, and multi-factor authentication, across all apps running on the same backend.

Device Ownership is a first-class concept in Connhex: a device can be claimed by a user, transferred, and shared with defined permissions. This is the model that allows an end user's app to see only their devices, while an installer's dashboard shows all the devices they manage.

Connhex Resources provides a flexible, app-scoped key-value store for product-specific application data, accessible via API. Rather than running a separate backend for domain logic, Resources act as a built-in data layer: a pool monitoring app stores pool equipment configuration here; an HVAC app stores installation parameters per thermostat. The data model is fully custom.

Connhex Notifications delivers native push notifications to iOS and Android devices, as well as in-app messages, sent using your app's sender identity. Per-user delivery preferences and delivery receipts are built in.

Multiple product lines and brands run on a single Connhex instance: each app has its own namespace, branding, and feature configuration. There is no need to manage separate backend deployments per product.

See it in practice​

I discovered Connhex after an in-depth technological scouting phase. It has proven to be by far the best solution for our needs: nothing even comes close.

Paolo Zigoni

CTO - Astrel Group

Astrel Group runs four separate branded applications (Energy, Home, Wellness, and Fire) on a single shared Connhex backend. Each app has its own data model, access rules, and user experience, with no cross-contamination between business units. Four distinct connected product apps, one backend team, without building four separate IoT backends.

A thermostat companion app built with Connhex. The same interface ships with both dark and light themes, configured via the built-in theming system.

App-centric connected products are central to several verticals: Connhex for the Smart Home · Connhex for HVAC · Connhex for the Spa and Swimming Pool

Read the technical docs​

• Device Ownership, Introduction
• IAM, Introduction
• Connhex Auth, Overview