Device route architecture

The browser management plane and device data plane meet at backend services; a browser never calls the DDI gateway and a device never calls a browser BFF.

┌──────────────────────────── Device and terminal ────────────────────────────┐
│ Unified DDI SDK: Python │ Android/Kotlin │ C │ emulator                     │
└───────────────────┬────────────────────────────────┬────────────────────────┘
                    │ HTTPS 443                      │ MQTT 8883
                    │ identify, provision,           │ telemetry, attributes,
                    │ rotate, time, OTA              │ commands, shared config
                    ▼                                ▼
         ┌──────────────────────┐         ┌──────────────────────┐
         │ things.flexgalaxy.ai │         │ things.flexgalaxy.ai │
         │ DDI HTTPS edge       │         │ shared EMQX listener │
         └──────────┬───────────┘         └──────────┬───────────┘
                    │ mTLS identity +                │
                    │ internal workload trust        │
                    ▼                                ▼
         ┌──────────────────────┐         ┌──────────────────────┐
         │ ddi-gateway          │◄────────┤ shared subscription  │
         │ enrollment + OTA     │────────►│ + down-channel       │
         └───────┬───────┬──────┘         └──────────┬───────────┘
                 │       │                           │
        identify │       │ OTA                       │ Kafka / workload JWT
       provision │       │ relay                     │
          rotate ▼       ▼                           ▼
         ┌────────────┐ ┌────────────┐       ┌──────────────────────┐
         │ TrustMint  │ │ HawkBit    │       │ TrustMint services   │
         │ ThingMake  │ │ private    │       │ ThingIO / ThingHub   │
         │ device CA  │ │ shared-svc │       │ telemetry + commands │
         └────────────┘ └─────▲──────┘       └──────────────────────┘
                              │ rollout and assignment management
                    ┌─────────┴──────────┐
                    │ Bazaar services    │
                    │ Dev2M / OTAForge   │
                    └─────────▲──────────┘
                              │ browser + DotID user authorization
                    ┌─────────┴──────────┐
                    │ Authorized user    │
                    │ browser            │
                    └────────────────────┘

The public host deliberately hides backend product names and infrastructure. HawkBit, Kafka, internal TrustMint routes, and server-held tokens remain private.

Composite products

A customer-visible product can contain more than one DDI identity. Give each computer that independently opens MQTT and OTA sessions its own certificate and thing_id, then group those identities under one management-plane asset. A non-networked MCU can remain a component of its controller, with telemetry and OTA installation proxied by that controller. See Composite robot terminal design for the complete two-device example.

Which calls use DDI

• Device-originated identity, telemetry, attributes, commands, time, and OTA use the DDI device surface when that capability is marked live.

• Bazaar management calls remain in Bazaar. DDI does not carry Marketplace, EntitleKit approval/billing, publication, or rollout-authoring traffic. A future certificate-bound device license-status route may be exposed by DDI, but the management workflow and external integrator AK/SK remain in EntitleKit.

• TrustMint management calls remain in TrustMint APIs. Device data reaches those services only after the gateway or broker authenticates and translates it.