Architektur

    Headless Telematics: fertiges Backend, Ihre Oberfläche

    Headless Telematics ist ein Architekturansatz, bei dem die Funktionen des Telematik-Backends über dokumentierte APIs erreichbar sind und die Anbieter-Oberfläche optional bleibt: Das Team baut die eigene Oberfläche auf einem fertigen Kern. Web- oder Mobiloberfläche, ein in den Geschäftsprozess eingebettetes Szenario, eine Integration ins Leitsystem — die Wahl liegt bei Ihnen, das Backend bleibt dasselbe.

    Dokumentation ansehen Zu Composable Telematics
    Dokumentierte APIIoT Query — LesezugriffDie Oberfläche steuern Sie
    Abfrage · 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;
    Antwort · Ergebniszeile
    { "device_id": 104,
    "device_time": "2026-07-21T14:02:11Z",
    "lat": 43.238, "lng": 76.889 }
    200 · raw_telematics_data · Lesezugriff
    Definition

    Was Headless Telematics ist

    Headless Telematics teilt das Produkt in zwei Teile: das Telematik-Backend mit Daten und Logik, über dokumentierte APIs erreichbar, und die Oberfläche, die das Team entwirft, das das Produkt baut. Der Kern bleibt derselbe, und darauf lässt sich jede beliebige Oberfläche aufsetzen. Navixy arbeitet nach diesem Prinzip: Die Funktionen des Telematik-Backends sind über dokumentierte APIs erreichbar, und welche Operationen ein Szenario genau umfasst, steht in der Dokumentation.

    • Bauen Sie ein Portal, eine mobile App, ein in den Geschäftsprozess eingebettetes Szenario oder eine Integration ins Leitsystem — die Oberfläche ist nicht auf eine Variante festgelegt.
    • Für Nutzererlebnis, Barrierefreiheit, Anwendungssicherheit, Support und Releases der eigenen Oberfläche ist Ihr Team verantwortlich.
    • Die dokumentierte API ist das Fundament der Architektur: Ein Kontrakt trägt Web-, Mobil- und eingebettete Szenarien — und perspektivisch auch einen Agenten über MCP. Navixy MCP
    Der Weg der Telematik

    Headless — die Stufe zwischen White Label und Composable Telematics

    Die Telematik geht den Weg von der fertigen Oberfläche über die Headless-Architektur zur composable Plattform — und weiter zur agent-ready Infrastruktur, in der nicht nur Menschen, sondern auch KI-Agenten Daten und Logik nutzen. Headless ist die Stufe, auf der das Backend bereits über APIs erreichbar ist und die Oberfläche zu Ihrem Feld der Differenzierung wird.

    • White Label und Headless sind benachbarte, gleichwertige Stufen: Wählen Sie die fertige Oberfläche dort, wo sie sich rechnet, und die eigene dort, wo die Oberfläche zu Ihrem Vorteil wird.
    • Headless gibt Ihnen bereits die eigene Oberfläche auf einem dokumentierten Backend — den Schritt zu Composable Telematics können Sie separat gehen, wenn Sie die Unabhängigkeit von Daten und Logik brauchen. Composable Telematics
    Wie es aufgebaut ist

    Die Anwendungsschicht verbindet Ihre Oberfläche mit dem Telematik-Backend

    Das Telematik-Backend garantiert

    Eine dokumentierte API und ein stabiles Datenschema — etwa die Tabelle raw_telematics_data.tracking_data_core in IoT Query.

    Datenschema
    Ihre Oberfläche verantwortet

    Die Anwendungsschicht ruft Operationen auf und holt nur die benötigten Felder; der Browser verbindet sich nie direkt mit dem Backend.

    Das Telematik-Backend garantiert

    Lesezugriff auf Telemetrie über die PostgreSQL-kompatible Verbindung von IoT Query.

    Verbindung einrichten
    Ihre Oberfläche verantwortet

    Nutzeridentifikation, Ablage der Secrets und Abfragelimits liegen bei Ihrer Lösung.

    Das Telematik-Backend garantiert

    Verbindungsdaten je Instanz — Mandantenisolation auf Backend-Ebene.

    Ihre Oberfläche verantwortet

    Die Zuordnung von Nutzer zu Mandant und die Schlüsselrotation stimmt das Team vor dem Start mit Navixy ab.

    Das Telematik-Backend garantiert

    Operative Logik in IoT Logic: Datenaufnahme, Transformationen, Aktionen und Routing.

    Logik-Operationen
    Ihre Oberfläche verantwortet

    Oberfläche, Barrierefreiheit, Fehlerbehandlung und Nutzersupport sind Ihr Verantwortungsbereich.

    Zwischen Oberfläche und Backend arbeitet die Anwendungsschicht Ihres Teams: Sie ruft dokumentierte Operationen auf, führt die Geschäftslogik und hält die Zugangsdaten des Anbieters auf dem Server, nicht im Browser.

    • Die Anwendungsschicht prüft Zugriffsrechte, berücksichtigt den Mandantenkontext und cacht Anfragen an das Backend.
    • Logs, Anfrage-IDs und Versionsprüfungen verbinden die Ebenen — ein Fehler lässt sich in Minuten diagnostizieren.

    Drei Operationen, die Ihre Headless-Architektur bestimmen

    Jede wird einzeln geprüft: Telemetrie lesen, Mandanten identifizieren und der Release-Lebenszyklus.

    SQL auf Live-Daten

    Verbindung einrichtenDatenschema
    01SELECT *
    02FROM raw_telematics_data.tracking_data_core
    03LIMIT 10;
    raw_business_dataraw_telematics_data
    tracking_data_core

    Dokumentierter, PostgreSQL-kompatibler Zugriff auf die Tabelle raw_telematics_data.tracking_data_core — Sie lesen die benötigten Felder direkt.

    Die Anwendungslogik — Datenaufnahme, JEXL-Transformationen und Routing — ist IoT Logic auf der Anwendungsschicht, nicht der Kontrakt des Backends. Logikoperationen

      Dokumentation ansehen
      Verantwortung verlagert sich

      Sie bekommen Ihre Oberfläche — und die Verantwortung dafür

      Dieser Tausch zahlt sich aus, wenn die Oberfläche Ihr Produkt am Markt abhebt und das Team bereit ist, sie zu betreiben: Authentifizierung, Releases, Störungen, Kundensupport. Schafft der Unterschied in der Oberfläche keinen spürbaren Kundenwert, bleibt White Label die schnelle und wirtschaftliche Wahl — gleichwertig, nicht zweite Wahl.

      • Ihr Team entwirft die Interaktion und verantwortet Barrierefreiheit, Frontend-Sicherheit, Releases und Kundensupport.
      • Backend- und Anwendungsverantwortliche legen Authentifizierung, Autorisierung, Abfragelimits, Versionierung und Eskalationsweg vor dem Start fest.
      • Ein Nutzerszenario läuft vollständig durch — verweigerter Zugriff, veraltete Daten, Teilausfall, API-Änderung auf Anbieterseite: So prüft man die Verantwortungsgrenze, nicht eine einzelne gelungene Abfrage.
      • White Label bleibt die schnelle und wirtschaftliche Wahl, wenn die eigene Oberfläche keinen spürbaren Kundenwert schafft. White-Label
      Backend-Grenzen
      Ihr Team verantwortet
      • Authentifizierung der Portalnutzer und Sitzungen
      • Datendarstellung, Barrierefreiheit, Fehlerbehandlung
      Die Plattform stellt bereit
      • Dokumentierte API des Telematik-Backends
      • Verbindungsdaten je Instanz
      Prüfung an einem Szenario

      Durchlaufen Sie ein Szenario — von der Verbindung bis zum Support

      So wird die Verantwortungsgrenze in der Praxis sichtbar, noch vor der ersten Zeile Oberfläche.

      1. 01Nutzer identifizieren
      2. 02Verbindung laut Dokumentation
      3. 03Datentabelle abfragen
      4. 04Darstellung und Support
      5. 05Monitoring und Änderungen
      Dokumentation ansehen
      Fragen zur Architektur

      Fragen zu Headless Telematics

      Was ist Headless Telematics?
      Ein Architekturansatz, bei dem das Backend über dokumentierte APIs erreichbar ist und die Anbieter-Oberfläche optional bleibt. Die Funktionen des Telematik-Backends sind über dokumentierte APIs erreichbar, und das Team baut die eigene Oberfläche auf einem fertigen Kern. Tracker, Kamera, TCU oder ein Fahrzeug ohne Display sind ein eigenes, hardwarebezogenes Thema; mit diesem Begriff hat das nichts zu tun.
      Heißt das, jede Backend-Funktion ist über die API verfügbar?
      Nicht automatisch. Welche Operationen und Rechte verfügbar sind, unterscheidet sich je nach Produktoberfläche — prüfen Sie das für jedes Szenario in der aktuellen Dokumentation, bevor Sie die Oberfläche entwerfen.
      Wer ist im Modell Headless Telematics für die Sicherheit verantwortlich?
      Die Verantwortung ist entlang der Backend-Grenze geteilt. Navixy schützt das Telematik-Backend innerhalb der vereinbarten Grenzen; Ihr Team verantwortet die eigene Oberfläche, Sitzungen, Integrationen und die operativen Prozesse darum herum.
      Wann ist White Label die bessere Wahl als Headless?
      Wenn die eigene Oberfläche keinen spürbaren Kundenwert schafft. Eine fertige Oberfläche unter Ihrer Marke startet ohne Frontend-Entwicklung. White Label und Headless sind gleichwertige Stufen: Wählen Sie danach, wo der Unterschied in der Oberfläche für den Markt tatsächlich zählt. White-Label
      Sollte der Browser die Telematik-API direkt aufrufen?
      In der Regel ist eine von Ihrem Team betriebene Anwendungsschicht zuverlässiger. Die Anwendungsschicht bündelt Autorisierung, Mandantenkontext, Secrets, Abfragelimits und den Umgang mit anbieterseitigen Änderungen an einer Stelle — einmal, statt in jeder Client-App einzeln.
      Wie prüft man die Headless-Architektur vor dem Start?
      Durchlaufen Sie ein reales Nutzerszenario vollständig. Prüfen Sie beim Szenario mit dem Lesen der letzten Koordinaten nicht nur die erfolgreiche Abfrage, sondern auch verweigerten Zugriff, veraltete oder fehlende Daten, Timeouts, Teilausfall, Schemaänderung und den Eskalationsweg in den Support. Verbindung einrichtenDatenschema
      Lässt sich eine fertige Oberfläche als Ausweichlösung neben der Headless-Lösung behalten?
      Ja, sofern Produkt und kommerzielle Konditionen das zulassen. Headless Telematics macht die Anbieter-Oberfläche zur Option, nicht zur Pflicht — ob sich konkrete fertige und eigene Szenarien in Ihrem Deployment-Modell kombinieren lassen, klären Sie separat mit Navixy. White-Label
      Ab wann zahlt sich Headless Telematics aus?
      Wenn ein für den Kunden wichtiger Geschäftsprozess die Entwicklung einer eigenen Oberfläche rechtfertigt. Der Zeitrahmen hängt von der Reife der Oberflächen, dem Entwurf von Identität und Mandanten, der Anwendungsentwicklung, den Integrationstests, der Sicherheitsprüfung, der Beobachtbarkeit und dem Migrationsumfang ab — eine für alle Szenarien einheitliche Dauer gibt es nicht.
      Kann ein KI-Agent oder ein Entwicklerwerkzeug mit dem Headless-Backend arbeiten?
      Ja, über denselben dokumentierten Zugang wie eine gewöhnliche Integration. Navixy stellt MCP für Nutzer- und Admin-Panel-Konten bereit sowie ein öffentliches MCP zur Dokumentation. Der Agent durchläuft dieselbe Authentifizierung und arbeitet in denselben Zugriffsgrenzen wie jede Anwendung. Navixy MCP

      Bauen Sie Ihre Oberfläche auf dem dokumentierten Backend von Navixy

      Beginnen Sie mit einem Nutzerszenario: Bestimmen Sie die benötigten Backend-Operationen, die Verantwortungsbereiche und den Lebenszyklus — bevor das Team die erste Zeile Oberfläche schreibt.

      Dokumentation ansehen Zu Composable Telematics

      Headless Telematics öffnet das Backend über APIs — welche Operationen Ihr Szenario umfasst, prüfen Sie in der Dokumentation.