Spring naar hoofdinhoud

Integraties & API

Uw systemen blijven staan. Wij sluiten erop aan.

Deze pagina is geschreven voor IT- en implementatieteams. Ze beschrijft hoe gegevens tussen FastAssist24 en uw omgeving bewegen, hoe toegang wordt afgeschermd en welke grenzen gelden. Geen sleutels, geen voorbeeldtokens, geen interne implementatiedetails.

Uitwisselingsmodellen

Drie manieren om gegevens uit te wisselen

Welk model past, hangt af van uw omgeving. De drie modellen sluiten elkaar niet uit — in de praktijk worden ze vaak naast elkaar gebruikt.

Drie manieren om gegevens uit te wisselen
ModelRichtingTypische toepassingVoorwaarde aan uw kant
REST APIuw systeem → FastAssist24Interventies aanmaken, voertuigen registreren, dekking opvragen en de toestand van een dossier ophalen.Uw systeem kan uitgaande HTTPS-aanroepen doen en een sleutel meegeven in de autorisatieheader.
WebhooksFastAssist24 → uw systeemToestandswijzigingen van een dossier ontvangen zonder te blijven bevragen.U stelt een bereikbaar HTTPS-eindpunt beschikbaar dat de melding aanneemt en bevestigt.
Gestructureerde import / exportbeide richtingenVoertuiglijsten, dekkingsconfiguraties en interventiegegevens in bestandsvorm uitwisselen.Geschikt voor omgevingen zonder directe API-toegang of met een vast exportvenster.

De volledige endpointreferentie en de veldspecificaties worden bij de technische intake ter beschikking gesteld. Ze worden hier niet gepubliceerd.

Toegang en sleutelbeheer

Wie mag wat, en waarmee

Toegang tot de API staat los van toegang tot het portaal. Beide zijn per organisatie afgebakend.

Sleutel per organisatie of partner
Elke B2B-organisatie en elke partner werkt met een eigen sleutel. Een sleutel geeft nooit toegang tot gegevens van een andere organisatie.
Gehashte opslag
Sleutels worden uitsluitend als SHA-256-hash bewaard. De sleutel zelf is na uitgifte niet opnieuw opvraagbaar.
Intrekbaar per sleutel
Een sleutel kan afzonderlijk worden ingetrokken zonder de overige integraties te onderbreken.
Tenant-isolatie
Gegevens van organisaties zijn strikt gescheiden in een multi-tenant model. Die afbakening geldt zowel voor de API als voor het portaal.
Rolgebaseerde toegang
Rollen en rechten zijn gescheiden voor platform, B2B-organisaties en providers.
Auditlog per dossier
Elke toestandswijziging en handeling is traceerbaar met volledig tijdspad — ongeacht of ze via het portaal of via de API gebeurde.

Idempotentie

Een herhaalde aanroep maakt geen tweede dossier

Netwerkfouten, time-outs en herhaalpogingen horen bij elke integratie. Schrijfacties zijn daarom idempotent: u geeft bij het aanmaken uw eigen referentie mee. Wordt dezelfde referentie opnieuw aangeboden, dan krijgt u het bestaande dossier terug in plaats van een duplicaat.

Hetzelfde principe geldt aan administratieve zijde bij de verwerking van annuleringen en terugbetalingen.

  1. aanroep 1 · referentie ORD-8841dossier aangemaakt
  2. time-out aan uw kantgeen bevestiging ontvangen
  3. aanroep 2 · dezelfde referentie ORD-8841hetzelfde dossier teruggegeven
  4. resultaatéén dossier, geen dubbele interventie
Illustratief voorbeeld · fictieve referentie

Toestandsvocabulaire

De toestanden die een interventiedossier doorloopt

Dit is het vocabulaire dat uw systeem terugkrijgt. Het is identiek aan wat uw medewerkers in het portaal zien.

De toestanden die een interventiedossier doorloopt
ToestandWat er gebeurd is
In behandelingDe aanvraag is geregistreerd en wacht op toewijzing aan een provider.
GeaccepteerdEen provider heeft de opdracht aanvaard. De toewijzing ligt vast.
OnderwegDe provider is onderweg naar de opgegeven locatie.
Ter plaatseDe provider is ter plaatse bij het voertuig.
VoltooidDe interventie is afgerond en het dossier is administratief verwerkbaar.
GeannuleerdHet dossier is stopgezet. De reden wordt in het dossier vastgelegd.

Systeemcategorieën

Waarmee organisaties in de praktijk koppelen

Onderstaande categorieën komen het vaakst voor. Elke koppeling verloopt via één van de drie uitwisselingsmodellen hierboven.

  • Fleet systemen
  • ERP platformen
  • Claims platformen
  • Dispatch systemen
  • Partner API's
  • Boekhouding & facturatie
  • Realtime events
  • Import / Export
  • Messaging systemen
  • Verhuurpartners
  • Betaalproviders
  • Rapportage & analytics

Integratiegrenzen

Wat wij vooraf willen vastleggen

  • Of een koppeling haalbaar is, hangt af van uw omgeving, toegangsrechten, gegevensformaat en technische validatie. Dat wordt per traject bekeken en niet vooraf beloofd.
  • Wij publiceren geen sleutels, geen voorbeeldtokens en geen interne implementatiedetails. De technische documentatie verloopt via de intake.
  • Een integratie wordt eerst in een afgebakende omgeving getest voordat ze op live dossiers wordt aangesloten.
  • De juistheid en de rechtsgrond van de gegevens die uw systeem aanlevert, blijven uw verantwoordelijkheid. De verwerkingsafspraken worden contractueel vastgelegd.
  • Wat op deze pagina staat, beschrijft de huidige werking. Over toekomstige mogelijkheden doen wij hier geen toezeggingen.

Implementatietraject

Van intake tot gefaseerde opschaling

  1. 01

    Operationele intake

    We brengen uw huidige intake, dispatch, opvolging en rapportering in kaart.

  2. 02

    Configuratie

    Diensten, rollen, providers en SLA-regels afgestemd op uw werking.

  3. 03

    Gecontroleerde pilot

    Een afgebakende live-omgeving; u meet dispatch, acceptatie en SLA op eigen interventies.

  4. 04

    Gefaseerde opschaling

    Uitbreiding per regio, vloot of dienst — met rapportering en integratiepositionering.

Ontworpen om aan te sluiten op bestaande fleet-, leasing-, verzekerings- en mobiliteitsprocessen. Belgische lancering, ontworpen voor Europese schaal.

Laat ons uw omgeving bekijken.

Bij een technische intake nemen we uw systemen, toegangsrechten en gegevensformaten door, en bepalen we welk uitwisselingsmodel past.

Operationele demo · 30 minuten · geen verplichtingen