Architecture

    Headless Telematics: a ready backend, your interface

    Headless Telematics is an architectural approach where telematics backend capabilities are reachable through documented APIs and the vendor interface is optional: your team builds its own interface on a ready core. A web or mobile interface, a workflow embedded in a business process, an integration with your operations system — the choice is yours, and the backend stays the same.

    Read the documentation Go to Composable Telematics
    Documented APIIoT Query — read accessThe interface is yours to control
    Request · SQL
    SELECT device_id, device_time, lat, lng
    FROM raw_telematics_data.tracking_data_core
    WHERE device_id = 104
    ORDER BY device_time DESC
    LIMIT 1;
    Response · result row
    { "device_id": 104,
    "device_time": "2026-07-21T14:02:11Z",
    "lat": 43.238, "lng": 76.889 }
    200 · raw_telematics_data · read access
    Definition

    What Headless Telematics is

    Headless Telematics splits the product into two parts: a telematics backend — data and logic — exposed through documented APIs, and an interface designed by the team building the product. The core stays the same, and any interface can be built on top of it. Navixy works this way: telematics backend capabilities are available through documented APIs, and the exact set of operations for each use case is described in the documentation.

    • Build a portal, a mobile app, a workflow embedded in a business process, or an integration with your operations system — you are not limited to a single interface.
    • Your team owns the user experience, accessibility, application security, support, and releases of the interface it builds.
    • The documented API is the foundation of the architecture: one contract serves web, mobile, and embedded use cases — and, in time, an agent through MCP. Navixy MCP
    The telematics path

    Headless is the step between white label and Composable Telematics

    Telematics moves from a ready interface through a headless architecture to a composable platform — and on to agent-ready infrastructure, where data and logic are used not only by people but by AI agents. Headless is the step where the backend is already exposed through APIs and the interface becomes your field for differentiation.

    • White label and Headless are adjacent, equal steps: choose a ready interface where it pays off, and a custom one where the interface becomes your advantage.
    • Headless already gives you a custom interface on a documented backend — the step to Composable Telematics can come later, when you need data and logic to be independent. Composable Telematics
    How it works

    An application layer connects your interface to the telematics backend

    The telematics backend guarantees

    A documented API and a stable data schema — for example, the raw_telematics_data.tracking_data_core table in IoT Query.

    Data schema
    Your interface owns

    The application layer calls operations and reads only the fields it needs; the browser never connects to the backend directly.

    The telematics backend guarantees

    Read access to telemetry through the PostgreSQL-compatible IoT Query connection.

    Connection setup
    Your interface owns

    User identity, secrets storage, and query limits sit on your solution's side.

    The telematics backend guarantees

    Per-instance connection credentials — tenant isolation at the backend level.

    Your interface owns

    Your team aligns user-to-tenant mapping and key rotation with Navixy before launch.

    The telematics backend guarantees

    Operational logic in IoT Logic: ingestion, transformations, actions, and routing.

    Logic operations
    Your interface owns

    The interface, accessibility, error handling, and user support are your responsibility.

    Between the interface and the backend runs an application layer your team owns: it calls documented operations, carries business logic, and keeps the vendor credentials on the server, not in the browser.

    • The application layer checks access rights, applies tenant context, and caches requests to the backend.
    • Logs, request identifiers, and version checks tie the layers together — a failure can be diagnosed in minutes.

    Three operations that define your headless architecture

    Each one stands on its own: telemetry reads, tenant identity, and the release lifecycle.

    SQL against live data

    Connection setupData schema
    01SELECT *
    02FROM raw_telematics_data.tracking_data_core
    03LIMIT 10;
    raw_business_dataraw_telematics_data
    tracking_data_core

    Documented PostgreSQL-compatible access to the raw_telematics_data.tracking_data_core table — read the fields you need directly.

    Applied logic — ingestion, JEXL transformations, and routing — is IoT Logic at the application layer, not part of the backend contract. Logic operations

      Read the documentation
      A shift in responsibility

      You gain your interface — and responsibility for it

      This trade pays off when the interface sets your product apart in the market and your team is ready to operate it: authentication, releases, incidents, customer support. When interface differences create no noticeable value for customers, white label stays a fast, cost-effective choice — an equal, not a fallback.

      • Your team designs the interaction and owns accessibility, frontend security, releases, and customer support.
      • Backend and application owners pin down authentication, authorization, query limits, versioning, and the escalation path before launch.
      • One user workflow runs end to end — denied access, stale data, partial failure, a provider-side API change: that is how you test the responsibility boundary, not a single lucky request.
      • White label stays a fast, cost-effective choice when a custom interface creates no noticeable value for the customer. White-label
      Backend boundary
      Your team owns
      • Portal user authentication and sessions
      • Data presentation, accessibility, error handling
      The platform provides
      • Documented telematics backend API
      • Per-instance connection credentials
      One use case, end to end

      Walk one use case — from connection to support

      That makes the responsibility boundary visible in practice, before the first line of interface.

      1. 01User identity
      2. 02Connect per the documentation
      3. 03Query the data table
      4. 04Display and support
      5. 05Monitoring and change
      Read the documentation
      Architecture questions

      Headless Telematics questions

      What is Headless Telematics?
      It's an architectural approach where the backend is exposed through documented APIs and the vendor interface is optional. Telematics backend capabilities are available through documented APIs, and the team builds its own interface on a ready core. A tracker, camera, TCU, or screenless vehicle is a separate, hardware topic; it has nothing to do with this term.
      So is every backend feature available through an API?
      Not automatically. The set of available operations and permissions differs by product surface — check it against the current documentation for each use case before you design the interface.
      Who owns security in the Headless Telematics model?
      Responsibility is split along the backend boundary. Navixy secures the telematics backend within agreed boundaries; your team owns its interface, sessions, integrations, and the operational processes around it.
      When is white label the better choice over Headless?
      When a custom interface creates no noticeable value for customers. A ready interface under your brand launches without frontend development. White label and Headless are equal steps: choose based on where the interface difference genuinely matters to the market. White-label
      Should the browser call the telematics API directly?
      It's usually more robust to go through an application layer your team controls. The application layer centralizes authorization, tenant context, secrets, query limits, and handling of provider-side changes — once, rather than in every client app separately.
      How do you validate a headless architecture before launch?
      Walk one real user workflow end to end. For a last-known-coordinates read, test not only the successful query but also denied access, stale or missing data, timeouts, partial failure, a schema change, and the support escalation path. Connection setupData schema
      Can we keep the ready interface as a fallback alongside a headless solution?
      Yes, where the product and commercial terms allow it. Headless Telematics makes the vendor interface an option, not a requirement — confirm with Navixy separately whether specific ready and custom paths can coexist in your deployment. White-label
      When does Headless Telematics start to pay off?
      When a business process that matters to the customer justifies building a custom interface. The timeline depends on interface readiness, identity and tenant design, application development, integration tests, security review, observability, and migration scope — there's no single timeline for every case.
      Can an AI agent or developer tool work with a headless backend?
      Yes, through the same documented access as any other integration. Navixy publishes MCP for user and Admin Panel accounts, plus a public MCP for the documentation. An agent goes through the same authentication and works within the same access boundaries as any application. Navixy MCP

      Build your interface on Navixy's documented backend

      Start with one user workflow: identify the backend operations you need, the responsibility boundaries, and the lifecycle — before your team writes the first line of interface.

      Read the documentation Go to Composable Telematics

      Headless Telematics exposes the backend through APIs — check the set of operations for your use case in the documentation.