Onze klant biedt een multimobiliteitsplatform waarmee bedrijven alle mobiliteitsvormen vanuit een plek beheren: lease-auto's, fietsen, OV-kaarten, deelauto's en thuiswerkvergoedingen. Het idee is simpel. De technische realiteit niet.
Het probleem: 150 bronnen, 150 formaten
Elke mobiliteitsaanbieder levert data op zijn eigen manier. Leasemaatschappij A stuurt CSV-bestanden per e-mail. OV-provider B heeft een REST API met OAuth2-authenticatie. Fietsleverancier C werkt met SFTP-uploads in een eigen XML-schema. Een deelautoplatform stuurt webhook-events in real-time. En ze definieren allemaal hun eigen velden, datumformaten en statuswaarden.
Handmatig koppelen was geen optie. Het team had al drie maanden besteed aan het handmatig importeren van data van de eerste 40 providers. Bij 150+ en groeiend zou het team permanent bezig zijn met dataverwerking in plaats van productontwikkeling. De foutpercentages liepen op: verkeerd gekopieerde bedragen, dubbele registraties, en timestamps die niet overeenkwamen tussen systemen.
Eerste poging: directe koppelingen
De eerste aanpak van het interne team was om per provider een maatwerk-koppeling te schrijven. Dat werkte voor de eerste 10 providers, maar elke koppeling had zijn eigen foutafhandeling, eigen retry-logica en eigen manier van data-opslag. Onderhoud werd een nachtmerrie. Als een leasemaatschappij haar API-versie veranderde, moest iemand de hele koppeling opnieuw testen. Er was geen standaard, geen monitoring, geen manier om te zien welke datastromen het deden en welke niet.
De oplossing: gestandaardiseerde adapters
Wij ontwikkelden een adapter-framework dat elke provider via een gestandaardiseerd interface koppelt aan het platform. Het framework definieert een contract: elke adapter moet data aanleveren in een uniform formaat met vaste velden voor voertuigtype, kosten, CO2-uitstoot, datum en gebruiker. Hoe de adapter die data intern ophaalt, is zijn eigen zaak.
Concreet: een CSV-adapter leest e-mailbijlagen via IMAP, parst het bestand en mapt de kolommen naar het standaardformaat. Een API-adapter doet een authenticated GET-request, paginateert door de resultaten en normaliseert de JSON. Een SFTP-adapter pollt een directory op nieuwe bestanden. Maar ze leveren allemaal hetzelfde output-formaat.
De orchestratie loopt via n8n. Datastromen worden gepland op vaste intervallen (meestal elk uur of elke nacht), uitgevoerd, gevalideerd tegen een JSON-schema, en bij fouten automatisch opnieuw geprobeerd met exponential backoff. Bij drie mislukte pogingen gaat er een Slack-alert naar het team. Alle data wordt opgeslagen in PostgreSQL met een volledige audit trail: we weten precies wanneer welke data binnenkwam en van welke bron.
Wat we tegenkwamen
De grootste uitdaging was niet de techniek, maar de datakwaliteit. Sommige providers leverden bedragen in centen, andere in euros. Datumvelden kwamen in zes verschillende formaten. Een leasemaatschappij stuurde dezelfde data drie keer als hun export vastliep. We moesten deduplicatie inbouwen, valutaconversie, en een flexibele datumparser die alles van ISO 8601 tot "15-mrt-24" aankon.
Een andere les: SFTP-servers van grotere bedrijven zijn verbazingwekkend onbetrouwbaar. Connectietimeouts, bestanden die halverwege verdwijnen, en authenticatie die zonder waarschuwing verandert. We hebben uiteindelijk een retry-mechanisme met health checks gebouwd dat proactief controleert of een SFTP-verbinding nog werkt voordat we afhankelijk worden van de data.
Resultaten
De integratietijd voor een nieuwe provider daalde van gemiddeld twee weken naar twee dagen. Het meeste werk zit nu in het begrijpen van de data, niet in het bouwen van de koppeling. Alle 150+ datastromen draaien autonoom zonder handmatige tussenkomst. Het platform bedient inmiddels meer dan 45 bedrijven met complete, actuele mobiliteitsdata.
Het monitoring-dashboard laat real-time zien welke adapters draaien, hoeveel records er zijn verwerkt, en welke fouten er optreden. Het team bekijkt dit dashboard elke ochtend en grijpt alleen in bij rode alerts. De rest draait vanzelf.
Wat andere platforms hiervan kunnen leren
Schaalbaarheid begint bij standaardisatie. Niet elk probleem is een AI-probleem. Soms is het antwoord een goed ontworpen datamodel, gestandaardiseerde interfaces en betrouwbare orchestratie. De technologie hoeft niet spectaculair te zijn om spectaculaire resultaten te leveren.
De belangrijkste les: investeer vroeg in monitoring en foutafhandeling. Bij 10 providers kun je fouten handmatig oplossen. Bij 150 niet. De adapters zelf zijn relatief simpel. De infrastructuur eromheen, de retry-logica, de alerting, de deduplicatie, dat is waar het verschil zit tussen iets dat werkt en iets dat betrouwbaar is.
