Composable Telematics

    Telematics as a platform you build on

    Navixy is a composable platform: a catalog of capabilities — from ready-made operational visibility (Location Intelligence) to data orchestration (IoT Logic), SQL access to telemetry (IoT Query), and a product under your own brand. Take the whole kit or individual primitives and build your product.

    Documentation Discuss the architecture with an engineer
    In telematics since 2005800K+ online assetsCustomers in 130+ countries
    IoT Logic · telemetry in motion
    In · raw device payload
    { "adc1": 156, "din": 5, "lat": 43.238, "lng": 76.889 }
    Out · normalized telemetry
    { "fuel_level": 62.4, "ignition": true, "location": ... }
    NavixyYour MQTT broker
    Flow active · decode → transform → route
    Beyond the monolith

    Everyone has the features. The question is whose data and whose roadmap

    A monolithic platform covers the standard tasks: tracking, reports, notifications. But the data is locked inside, the API is secondary, and every non-standard feature is a ticket to the vendor and months in someone else's roadmap. As long as you resell someone's platform, your product is their product with your logo in the corner.

      Category definition

      What Composable Telematics means

      Composable Telematics is an approach in which a telematics product is assembled from independent platform capabilities with documented interfaces, instead of taken as a closed monolith. Each capability works on its own, connects to the others through APIs, and can be replaced without rewriting the whole stack. Telematics moves from white-label through headless to composable — and on to agent-ready, where AI agents — not just people — work with the platform.

      • Every capability is self-sufficient: Location Intelligence, IoT Logic, IoT Query, and the application layer each work on their own. There are no all-or-nothing dependencies.
      • Interfaces are open in both directions: you can enter any capability with your own data and exit to your own systems — through API, SDK, and MCP.
      • The catalog is open: device and OEM sources, AI-agent access, and integrations add to the core. The list of capabilities grows rather than being fixed by a single product.

      The platform capability catalog

      The core is the four capabilities below; start from ready-made visibility or drop down to the data. The platform is wider still: APIs and SDKs, device and OEM support, and AI-agent access through MCP.

      Location Intelligence

      Ready-made operational visibility: a live map, geofences, event rules, route replay (Time Machine), reports, and secure geo-links. It turns a device signal into an operational picture of the field — with no interface development. DocumentationDocumentation

      IoT Logic

      Ingest data from devices and OEM sources, decode protocols, enrich and route the streams — into your systems or further down the stack. New sources and processing rules are configured in the flow builder, with no platform release. DocumentationIoT LogicOEM telematics

      IoT Query

      PostgreSQL-compatible SQL access to raw telematics data. BI dashboards, ML models, your own analytics — by direct query, not a CSV export. Connection setupData schemaIoT Query

      Application layer

      White-label web and mobile apps: domain, logos, and color themes under your own brand. Launch with no front-end development. When you need your own interface, the same data is available headless, through the API. White-labelHeadless

      Architecture

      Connect at any layer. Pull the data wherever you need it

      Telemetry moves bottom-up: from devices through IoT Logic to the data layer, Location Intelligence, and applications. But you don't have to use the whole stack. Plug in your own source, interface, or storage wherever your architecture needs it. Logic operationsData access

      • Replace one layer instead of migrating the whole stack.
      Agent-ready

      An AI agent is as much a platform client as your application

      The Navixy MCP server opens account data to agents: telemetry, objects, rules, reports. The agent authenticates, works within account permissions, and needs no separate integration. Ask the agent “which vehicles were idle for more than two hours yesterday” — and it runs the query itself. Navixy MCP

        Navixy MCP · agent console
        Agent: which vehicles were idle for more than two hours yesterday?
        Navixy MCP → authentication: account token (User MCP)
        IoT Query: 7 vehicles idle for more than 2 hours

        User MCP and Admin Panel MCP require account authentication; the docs MCP is public. The agent acts within the bounds of the account's permissions.

        Who it's for

        One infrastructure — different products

        The infrastructure is the same for TSPs, product teams, and engineering departments — but each group uses it in its own way.

        • TSPs and integrators: Stop reselling someone else's platform — ship an industry product: your brand, your pricing, your logic on top of ready infrastructure.
        • ISVs and vertical products: Telematics as a component: FSM, insurance, cold chain. Embed data and events into your product through the API, without building telemetry ingestion from scratch.
        • Enterprise engineering teams: Equipment data in your own warehouse and BI, by SQL query. Without a vendor dashboard that no one opens.
        The Navixy team are professional, courteous and always willing to listen. Great company and great people. This is the most comprehensive platform i have ever used. Its never been easier to integrate new devices.
        WM
        Warren M.
        Director · Information Technology and Services, 11-50 employees
        10K+
        completed projects
        800K+
        online assets
        130+
        customer countries

        Review from the Navixy customer review program.

        Frequently asked

        Questions about Composable Telematics

        Is Composable Telematics an industry standard?
        No — it's an architectural approach, not a certified standard. It's easy to verify: every capability has public documentation, the capabilities work independently, and the data is directly accessible. If any one of the three requires “talk to your account manager,” it isn't composable.
        Is having an API enough to make a platform composable?
        No. A monolith's API is usually secondary: it covers some of the functions and won't let you enter the stack with your own data. Composable means the API is the primary interface of every capability, and the platform's own UI is just one of its consumers. Logic operations
        Are Headless Telematics and Composable Telematics the same thing?
        Headless is a special case: data and logic without a ready-made interface. Composable is broader: the blocks — including the ready white-label interface — combine in any configuration. A headless scenario is always available in a composable stack; the reverse is not true. Headless
        Is white-label telematics already composable?
        On its own, no. With a typical vendor, white-label changes the styling but the stack stays monolithic: data, logic, and interface are one whole. Composable adds the essential part — the ability to take the data, replace a layer, or plug in your own. And white-label stays a legitimate delivery mode: in a composable platform it's one mode of the application layer, not a ceiling. White-label
        When is building the infrastructure yourself not worth it?
        When telematics isn't a product for you but a task: track a dozen vehicles, pull reports. Then a ready-made app is cheaper than any architecture. Composable pays off when you build a product for your own customers or embed telemetry into your own systems.
        What does Location Intelligence add on top of data ingestion?
        Ready-made operational visibility, with no interface development. A live map, geofences, event rules, route replay (Time Machine), reports, and secure geo-links work right away. It's a separate capability in the catalog: switch it on over IoT Logic, or replace it with your own interface through the API. DocumentationDocumentation
        Does Composable Telematics remove vendor lock-in?
        It reduces it; it doesn't remove it. Switching a capability is still work, but work of a bounded scope: you replace one layer, not the whole stack with a data migration. The key test — can you export all of your data through a standard path. In Navixy that's SQL access via IoT Query.
        What evidence should I ask a vendor for?
        Public API documentation for each capability, the data schema, a description of how to export everything, the list of supported device protocols, and the terms on which capabilities work separately. If the answer is “we'll send a deck,” the conclusion is obvious.
        Can I connect an AI agent or a developer tool to Navixy?
        An agent connects like any ordinary integration. User MCP and Admin Panel MCP work through account authentication; the docs MCP is public. The agent gets the same permissions and the same access control as any application. Navixy MCP

        Start with the documentation

        Work through the architecture yourself — or in 30 minutes with a Navixy engineer, on your own scenario.

        Documentation Talk to an engineer

        Start with a single capability or assemble the whole stack for your scenario.