Flottenmanagement-Systeme: Fahrzeugdaten von der Aufnahme bis zur AusflottungAlle Fachgruppen

Flottenmanagement-Systeme: Fahrzeugdaten von der Aufnahme bis zur Ausflottung

Flottensysteme leben von Stammdaten, die heute abgetippt werden. Die Schnittstelle liest Zulassungsdokumente, Kennzeichen und Zustand aus Bild und PDF und gleicht Rückrufe über den ganzen Bestand ab — mit einem Aufruf je Prozessschritt.

Veröffentlicht: 2026-09-06Lesezeit: 6 minIntegrationen für Fachgruppen
IntegrationenFahrzeugdatenAPIDokumente & PDFVINBilderkennungPreis & Kalkulation
Kurz erklärt
Flottenmanagement-System
Ein Flottenmanagement-System verwaltet Fahrzeuge über ihren gesamten Lebenszyklus im Unternehmen: Aufnahme, Zuordnung zu Fahrern und Standorten, Wartung, Schäden, Rückgabe und Ausflottung. Genutzt wird es von Leasinggesellschaften, Autovermietern, Unternehmensflotten, Kommunen und Fuhrparkdienstleistern — und zunehmend von Autohäusern und Verwertern, die Flottenfahrzeuge übernehmen. Diese Seite richtet sich an die Anbieter solcher Systeme.

Wo im Prozess Daten fehlen

Ein Flottensystem ist so gut wie seine Stammdaten. In der Praxis entstehen sie an Stellen, an denen jemand ein Dokument abtippt oder ein Foto von Hand zuordnet. Typische Lücken:

  • Bei der Aufnahme. Der Fahrzeugschein wird abgetippt — bei internationalen Flotten aus Dokumenten, die je Land anders aufgebaut sind. Fehler in VIN, Typschlüssel oder Erstzulassung wandern in jede spätere Auswertung. Siehe Zulassungsbescheinigung: Die Felder, die im Betrieb zählen.
  • Bei Schaden- und Fahrermeldungen. Ein Foto kommt mit Kennzeichen, aber ohne Fahrzeugkennung; jemand sucht das Kennzeichen im Bestand und ordnet es zu.
  • Bei Rückrufen. Herstellerschreiben und Registermeldungen werden von Hand gegen den Bestand geprüft, oft erst, wenn ein Fahrer nachfragt.
  • Bei der Rückgabe. Der Zustand wird auf einem Protokoll angekreuzt, die Fotos liegen unstrukturiert daneben; bei Streit fehlt die Zuordnung von Befund zu Aufnahme.
  • Bei der Ausflottung. Verkauf, Export oder Verwertung werden ohne Zahlenbasis entschieden — und ohne die Frage, ob das Fahrzeug rechtlich noch Ware ist. Siehe Gebrauchtwagen oder Altfahrzeug? Die Abgrenzung beim Export.

Was die Schnittstelle liefert

ProzessschrittAufrufErgebnis
Aufnahme, deutscher FahrzeugscheinPOST /scanner/document/registrationFelder der Zulassungsbescheinigung Teil I, strukturiert
Aufnahme, Dokument aus 32 LändernPOST /scanner/document/registration/internationalNormalisierte Kernfelder plus jedes gelesene Feld in fields mit Aufdruck in sourceValue
Fahrzeug identifizierenGET /vin/{vin}/vehicleFahrzeugdaten und stabile tapiId; Provider 1 über den Redirect-Ablauf
Kennzeichen zuordnenPOST /vision/license-plateZeichen, Vergleichsform, Land, Sicherheit und Position — ohne Halterabfrage
Rückrufe prüfenGET /recalls/vehicles/{vin}Je Maßnahme Aktenzeichen, Register, Mangel, Abhilfe, Stop-Drive-Kennung, Match-Konfidenz
Rückgabe dokumentierenPOST /vision/condition-reportBefunde je Zone in fester Reihenfolge, Gesamteinstufung A/B/C
AusflottungPOST /vision/vehicle/elv-classification, GET /vin/{vin}/economic-evaluationAltfahrzeug-Einstufung; Erlöspotenzial min/average/max und Demontage-Ranking

Ein Ablauf von Anfang bis Ende

  1. Aufnahme. Das Zulassungsdokument geht als Bild oder PDF per fileUrl an POST /scanner/document/registration/international. Die normalisierten Kernfelder füllen die Stammdaten, sourceValue bewahrt den Aufdruck. Namen, Adressen, Kennzeichen und VIN werden nie übersetzt.
  2. Identifikation. Die erkannte VIN geht an GET /vin/{vin}/vehicle; Provider 2 und 3 antworten direkt, Provider 1 antwortet Drittsystemen mit redirect_required. Dann legt das Backend über POST /vin/redirect-sessions eine Session aus vin, returnUrl und state an und leitet den Nutzer auf redirectUrl; der Abgleich läuft in der tapinoma-Oberfläche, der Rücksprung bringt status=completed, tapiId und state — nie Fahrzeugdaten. Die Session verfällt nach zehn Minuten. Aufbau der Nummer in VIN: Die Fahrgestellnummer verstehen, prüfen und nutzen.
  3. Betrieb. Eine Schadenmeldung kommt mit Foto. POST /vision/license-plate liefert aus bis zu 3 Aufnahmen Zeichen, Vergleichsform und Land nach ISO 3166-1 alpha-2; die Vergleichsform wird gegen den Bestand geprüft.
  4. Rückrufe. Ein nächtlicher Durchlauf ruft GET /recalls/vehicles/{vin} für den Bestand auf; die VIN wird nur aus dem eigenen, zuvor abgeglichenen Bestand aufgelöst, ohne Lieferantenabruf. Eine Maßnahme mit Stop-Drive-Kennung erzeugt eine Sperre und eine Aufgabe.
  5. Rückgabe. Bis zu 8 Rundgang-Aufnahmen gehen an POST /vision/condition-report. Die Befunde je Zone — Front, Flanke links, Flanke rechts, Heck, Dach, Innenraum, Motorraum, Sonstiges — und die Gesamteinstufung landen im Rückgabeprotokoll; welche Aufnahme zu welcher Zone gehört, hält das Flottensystem selbst fest, die Antwort nennt nur imageCount.
  6. Ausflottung. POST /vision/vehicle/elv-classification klärt aus 1 bis 10 Aufnahmen, ob ein Altfahrzeugverdacht besteht; gutachten_empfohlen heißt, dass ein Gutachten die Entscheidung tragen muss. Für Verkauf oder Verwertung liefert GET /vin/{vin}/economic-evaluation mit provider=1 das Erlöspotenzial der Teile als min, average und max — sofort 200, wenn Teileliste und Bewertungen vorliegen, sonst 202 mit Job-ID und Ergebnis über GET /vin/economic-evaluation/jobs/{jobId}. Einordnung in Unfallfahrzeuge: Totalschaden, Restwert und was für den Verwerter zählt und Fahrzeugankauf: Was ein Altfahrzeug wirklich wert ist.
Zulassungsdokument auslesen
curl \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"fileUrl": "<FILE_URL>"}' \
  'https://api.tapinomahub.com/scanner/document/registration/international'

Der Einbau

  1. Schlüssel serverseitig halten. Der X-Api-Key liegt in der Konfiguration des Backends. Fahrer-Apps und Browser sprechen mit dem eigenen Server, nie mit der Schnittstelle direkt.
  2. Mit einem Endpunkt beginnen. Für ein Flottensystem ist das meist das Auslesen des Zulassungsdokuments bei der Aufnahme; wer einen abgeglichenen VIN-Bestand hat, beginnt mit dem Rückrufabgleich.
  3. Feldzuordnung festlegen. Welches Dokumentfeld füllt welches Stammdatenfeld? fields und sourceValue bleiben erhalten, jedes Feld trägt seine Herkunft: Dokument, Abgleich oder Hand.
  4. Leerbefund und Fehler trennen. 404 vehicle_not_found ist ein fachlicher Leerbefund, kein technischer Fehler; ein null-Feld bleibt leer und erzeugt eine Aufgabe. Eine durchgeführte Bildanalyse wird berechnet, auch ohne Treffer.
  5. Lang laufende Aufrufe abholen. Ein 202 bringt Location, Retry-After und eine Job-ID. Das Backend fragt den Job-Endpunkt ab und schreibt das Ergebnis, sobald es vorliegt.
  6. Schrittweise ausrollen. Erst ein Mandant, dann alle. GET /client/usage zeigt, welche Aufrufe wie oft laufen; X-Tapinoma-Usage-Warning meldet knappes Guthaben.

Worauf zu achten ist

  • `Idempotency-Key` setzen. Ein wiederholter Aufruf nach Netzabbruch darf keine zweite Analyse auslösen; X-Tapinoma-Idempotent-Replay kennzeichnet die Wiederholung. Aufrufe, die einen Schlüssel ausgeben, werden nicht wiederholt — nach einem Timeout den Bestand über GET /client/users abgleichen.
  • Leere Felder leer lassen. Was Dokument oder Bild nicht hergeben, kommt als null. Ein plausibler Standardwert ist gefährlicher als eine sichtbare Lücke.
  • `tapiId` speichern. Sie ist stabil, und GET /vehicles/{tapiId} liefert die technischen Daten als Bestandteil des zuvor bezahlten VIN-Ablaufs — ohne zweiten Abgleich bei jedem Öffnen der Akte.
  • Schlüssel nie im Browser. Auch nicht in einer Fahrer-App oder einem Kiosk am Standort.
  • Rate-Limits je Mandant. Der Rückrufdurchlauf gehört in ein Zeitfenster, und PUT /client/users/{clientId}/rate-limits begrenzt, was ein einzelner Nutzer auslösen kann.
  • Ergebnisse prüfen. Sicherheit beim Kennzeichen, Match-Konfidenz beim Rückruf und A/B/C beim Zustand sind Angaben zur Belastbarkeit, keine Entscheidungen. Geschuldet ist die Analyse, die Verwendung liegt beim Kunden — rechtlich eingeordnet in Daten im Altfahrzeug: Was im Infotainment bleibt, wenn das Fahrzeug geht.

Was die Schnittstelle nicht tut

Sie ermittelt keinen Halter: POST /vision/license-plate liest das Kennzeichen vom Foto, ohne Register- oder Halterabgleich. Sie ersetzt kein Gutachten: Der Zustandsbericht ist eine Sichtprüfung ohne Reparatur- oder Restwertkalkulation, und gutachten_empfohlen bedeutet genau das. Sie garantiert keinen Preis: Die Wirtschaftlichkeitsanalyse nennt ein Erlöspotenzial aus Marktreferenzen, keinen Verkaufspreis. Der Rückrufabgleich ist eine baureihenbezogene Arbeitshilfe, keine fahrzeugindividuelle Auskunft des Herstellers. Provider 1 ist für Drittsysteme nur über den Redirect-Ablauf erreichbar. Und sie verkauft keinen Datenbestand: Geschuldet ist die Analyse und die Ausgabe des Ergebnisses. Was in die Verwertung geht, lässt sich mit belegten Sachdaten begleiten — siehe CO₂ und Gebrauchtteile: Was sich seriös sagen lässt.

Häufige Fragen

Kann die Schnittstelle zu einem Kennzeichen den Halter nennen?

Nein. POST /vision/license-plate liest Zeichen, Vergleichsform und Land vom Foto. Es gibt keine Halterabfrage und keinen Registerabgleich; die Zuordnung erfolgt im eigenen Bestand.

Warum antwortet Provider 1 mit redirect_required?

Weil Provider 1 von Drittsystemen nicht direkt abgerufen werden darf. Das Backend erstellt über POST /vin/redirect-sessions eine Session, der Nutzer gleicht in der tapinoma-Oberfläche ab, der Rücksprung bringt die tapiId. Provider 2 und 3 sind direkt abfragbar.

Wird eine Bildanalyse berechnet, wenn nichts erkannt wird?

Ja. Berechnet wird die durchgeführte Analyse, nicht der Treffer. Ein Leerbefund ist kein Fehler; erstattet wird nur, wenn die Analyse nicht erbracht werden konnte.

Wie binden wir viele Flottenkunden mit getrennter Abrechnung an?

Über POST /client/partner-workspaces: je Endkunde ein Aufruf mit externalReference, eigenem Schlüssel und Freischaltung über endpointKeys. Ein Vertrag, viele getrennt abrechenbare Workspaces.