Integrationen & API
Ihre Systeme bleiben bestehen. Wir docken an.
Diese Seite richtet sich an IT- und Implementierungsteams. Sie beschreibt, wie Daten zwischen FastAssist24 und Ihrer Umgebung fließen, wie der Zugriff abgesichert ist und welche Grenzen gelten. Keine Schlüssel, keine Beispiel-Token, keine internen Implementierungsdetails.
Austauschmodelle
Drei Wege, Daten auszutauschen
Welches Modell passt, hängt von Ihrer Umgebung ab. Die drei schließen einander nicht aus — in der Praxis werden sie oft nebeneinander eingesetzt.
| Modell | Richtung | Typische Anwendung | Voraussetzung auf Ihrer Seite |
|---|---|---|---|
| REST-API | Ihr System → FastAssist24 | Einsätze anlegen, Fahrzeuge registrieren, Deckung prüfen und den Zustand eines Vorgangs abrufen. | Ihr System kann ausgehende HTTPS-Aufrufe senden und einen Schlüssel im Autorisierungs-Header übergeben. |
| Webhooks | FastAssist24 → Ihr System | Zustandsänderungen eines Vorgangs empfangen, ohne dauerhaft abzufragen. | Sie stellen einen erreichbaren HTTPS-Endpunkt bereit, der die Meldung annimmt und bestätigt. |
| Strukturierter Import / Export | beide Richtungen | Fahrzeuglisten, Deckungskonfigurationen und Einsatzdaten in Dateiform austauschen. | Geeignet für Umgebungen ohne direkten API-Zugang oder mit festem Exportfenster. |
Die vollständige Endpunktreferenz und die Feldspezifikationen werden beim technischen Erstgespräch bereitgestellt. Sie werden hier nicht veröffentlicht.
Zugriff und Schlüsselverwaltung
Wer darf was, und womit
Der API-Zugriff ist vom Portalzugriff getrennt. Beide sind je Organisation abgegrenzt.
- Schlüssel je Organisation oder Partner
- Jede B2B-Organisation und jeder Partner arbeitet mit einem eigenen Schlüssel. Ein Schlüssel gewährt nie Zugriff auf Daten einer anderen Organisation.
- Gehashte Speicherung
- Schlüssel werden ausschließlich als SHA-256-Hash gespeichert. Der Schlüssel selbst ist nach der Ausgabe nicht erneut abrufbar.
- Einzeln widerrufbar
- Ein Schlüssel kann einzeln widerrufen werden, ohne die übrigen Integrationen zu unterbrechen.
- Mandantentrennung
- Daten der Organisationen sind in einem Multi-Mandanten-Modell strikt getrennt. Diese Abgrenzung gilt für die API ebenso wie für das Portal.
- Rollenbasierter Zugriff
- Rollen und Rechte sind für Plattform, B2B-Organisationen und Dienstleister getrennt.
- Audit-Log je Vorgang
- Jede Zustandsänderung und jede Handlung ist mit vollständigem Zeitverlauf nachvollziehbar — unabhängig davon, ob sie über das Portal oder die API erfolgte.
Idempotenz
Ein wiederholter Aufruf erzeugt keinen zweiten Vorgang
Netzwerkfehler, Zeitüberschreitungen und Wiederholungen gehören zu jeder Integration. Schreibvorgänge sind deshalb idempotent: Sie übergeben beim Anlegen Ihre eigene Referenz. Wird dieselbe Referenz erneut übermittelt, erhalten Sie den bestehenden Vorgang statt eines Duplikats.
Dasselbe Prinzip gilt auf administrativer Seite bei der Verarbeitung von Stornierungen und Rückerstattungen.
- Aufruf 1 · Referenz ORD-8841Vorgang angelegt
- Zeitüberschreitung auf Ihrer Seitekeine Bestätigung erhalten
- Aufruf 2 · dieselbe Referenz ORD-8841derselbe Vorgang wird zurückgegeben
- Ergebnisein Vorgang, kein doppelter Einsatz
Zustandsvokabular
Die Zustände, die ein Einsatzvorgang durchläuft
Das ist das Vokabular, das Ihr System zurückerhält. Es ist identisch mit dem, was Ihre Mitarbeitenden im Portal sehen.
| Zustand | Was geschehen ist |
|---|---|
| Ausstehend | Die Anfrage ist erfasst und wartet auf die Zuweisung an einen Dienstleister. |
| Angenommen | Ein Dienstleister hat den Auftrag angenommen. Die Zuweisung steht fest. |
| Unterwegs | Der Dienstleister ist auf dem Weg zum angegebenen Ort. |
| Vor Ort | Der Dienstleister ist beim Fahrzeug vor Ort. |
| Abgeschlossen | Der Einsatz ist abgeschlossen und der Vorgang administrativ verarbeitbar. |
| Abgebrochen | Der Vorgang wurde gestoppt. Der Grund wird im Vorgang festgehalten. |
Systemkategorien
Womit Organisationen in der Praxis koppeln
Die folgenden Kategorien treten am häufigsten auf. Jede Kopplung läuft über eines der drei Austauschmodelle oben.
- Flottensysteme
- ERP-Plattformen
- Schadensplattformen
- Dispatch-Systeme
- Partner-APIs
- Buchhaltung & Rechnungsstellung
- Echtzeit-Events
- Import / Export
- Messaging-Systeme
- Mietpartner
- Zahlungsanbieter
- Reporting & Analytics
Integrationsgrenzen
Was wir vorab festhalten möchten
- Ob eine Kopplung machbar ist, hängt von Ihrer Umgebung, den Zugriffsrechten, dem Datenformat und der technischen Validierung ab. Das wird je Projekt geprüft und nicht vorab zugesagt.
- Wir veröffentlichen keine Schlüssel, keine Beispiel-Token und keine internen Implementierungsdetails. Die technische Dokumentation läuft über das Erstgespräch.
- Eine Integration wird zuerst in einer abgegrenzten Umgebung getestet, bevor sie an echte Vorgänge angebunden wird.
- Die Richtigkeit und die Rechtsgrundlage der von Ihrem System gelieferten Daten bleiben in Ihrer Verantwortung. Die Verarbeitungsvereinbarungen werden vertraglich festgelegt.
- Diese Seite beschreibt die heutige Funktionsweise. Zu künftigen Möglichkeiten machen wir hier keine Zusagen.
Implementierungsweg
Vom Erstgespräch zur schrittweisen Skalierung
- 01
Operative Aufnahme
Wir erfassen Ihre heutige Aufnahme, Dispatch, Verfolgung und Ihr Reporting.
- 02
Konfiguration
Dienste, Rollen, Dienstleister und SLA-Regeln auf Ihren Betrieb abgestimmt.
- 03
Kontrollierter Pilot
Eine abgegrenzte Live-Umgebung; Sie messen Dispatch, Annahme und SLA an eigenen Einsätzen.
- 04
Stufenweise Skalierung
Ausbau je Region, Flotte oder Dienst — mit Reporting und Integrationspositionierung.
Entwickelt für den Anschluss an bestehende Flotten-, Leasing-, Versicherungs- und Mobilitätsprozesse. Belgischer Start, für europäischen Maßstab konzipiert.
Lassen Sie uns Ihre Umgebung ansehen.
In einem technischen Erstgespräch gehen wir Ihre Systeme, Zugriffsrechte und Datenformate durch und bestimmen, welches Austauschmodell passt.
Operative Demo · 30 Minuten · unverbindlich