Mijn software heeft geen API: wat nu?

Waarom een leverancier geen koppelvlak wil geven

Je stuit op dit probleem meestal pas als je iets wilt automatiseren. Facturen moeten van je boekhoudpakket naar je CRM, voorraad moet synchroniseren met je webshop, of je wilt een dashboard bouwen dat cijfers uit drie systemen samenvoegt. Dan blijkt: geen API, geen webhook, niets. Alleen een export-knop en een support-medewerker die zegt dat koppelingen "niet standaard ondersteund worden".

Daar zitten meestal drie redenen achter. De eerste is technisch: het pakket is oud, gebouwd voordat een API gangbaar was, en een koppelvlak toevoegen is voor de leverancier een groot project. De tweede is commercieel: sommige leveranciers verdienen aan koppelingen die zij zelf bouwen tegen uurtarief, en hebben geen belang bij een open API die klanten zelf laat koppelen. De derde is strategisch: een gesloten systeem maakt overstappen lastiger, en dat weet de leverancier.

Voor jou als ondernemer maakt de reden weinig uit. Je hebt een taak die je wilt automatiseren en een systeem dat niet meewerkt. De vraag is welke route je neemt, wat die kost, en waar het breekbaar wordt.

Route 1: handmatige export en import blijven doen

De simpelste route is niets veranderen. Je exporteert een Excel- of CSV-bestand uit systeem A en importeert dat handmatig in systeem B. Voor bedrijven die dit eenmaal per week of maand doen, is dit vaak de goedkoopste optie: geen kosten, geen technisch risico, geen afhankelijkheid van een externe partij.

De kwetsbaarheid zit in de mens die het doet. Bij ziekte, vakantie of verloop van personeel valt het proces stil of gaat het fout. Bestandsformaten veranderen soms na een update, waardoor de import plotseling niet meer klopt en niemand het meteen opmerkt. En hoe vaker je het moet doen, hoe groter de kans op fouten: een verkeerde kolom, een dubbele import, een vergeten week.

Deze route is verdedigbaar zolang de frequentie laag is en de gevolgen van een foutje klein zijn. Zodra je dagelijks moet exporteren, of zodra de data direct invloed heeft op facturatie of voorraad, wordt handmatig werk een risico dat je bedrijf groter maakt dan het zou moeten zijn.

Route 2: export op schema automatiseren

Veel pakketten zonder API bieden wel een vorm van geautomatiseerde export: een CSV-bestand dat elke nacht op een FTP-server verschijnt, een rapport dat automatisch per e-mail wordt verstuurd, of een gedeelde netwerkmap die elk uur ververst. Dat is geen API, maar het is ook geen handmatig werk meer.

Met een automatiseringstool zoals n8n, Make of Zapier kun je zo'n bestand oppikken zodra het verschijnt, de inhoud verwerken en doorzetten naar het volgende systeem. Dit noemen we in de praktijk een polling-koppeling: je checkt op vaste tijden of er nieuwe data is, in plaats van dat het systeem je actief informeert via een webhook. Het werkt, maar met vertraging: als de export om 3 uur 's nachts draait, weet je pas de volgende ochtend wat er gisteren is gebeurd.

De kosten zitten vooral in de bouw van de workflow: een paar honderd tot een paar duizend euro, afhankelijk van hoeveel logica erin zit en hoeveel foutafhandeling je wilt. De kwetsbaarheid zit in het bestandsformaat: verandert de leverancier iets aan de export zonder aankondiging, dan breekt de koppeling stil. Dat merk je pas als iemand vraagt waarom de cijfers niet kloppen. Bouw daarom altijd een controle in die meldt als het bestand een dag uitblijft of een andere structuur heeft dan verwacht. Meer over wat zo'n koppeling structureel kost lees je in wat kost een koppeling.

Route 3: screen scraping of RPA als noodgreep

Als er zelfs geen exportfunctie is, blijft er nog een lelijke maar werkende route over: een robot die het scherm bedient zoals een mens dat zou doen. Dit heet Robotic Process Automation (RPA) of screen scraping. De robot logt in, klikt door schermen, leest velden uit en voert data in, precies zoals een medewerker dat zou doen, maar dan geautomatiseerd.

Dit is de meest kwetsbare route van allemaal. Elke visuele wijziging in het pakket, een verschoven knop, een nieuw pop-upvenster, een tekstlabel dat verandert, kan de robot laten vastlopen. Onderhoud is structureel hoger dan bij een API-koppeling of een export op schema, omdat je feitelijk een interface nabootst die niet voor automatisering bedoeld is.

De kosten variëren sterk: eenvoudige scraping-taken zijn met tools als n8n of gespecialiseerde RPA-software relatief betaalbaar te bouwen, maar complexe schermflows met veel stappen kunnen net zo duur zijn als maatwerk. Ik adviseer deze route alleen als er echt geen andere optie is, en met het besef dat je een doorlopende onderhoudspost accepteert, geen eenmalige investering.

Route 4: de database rechtstreeks benaderen

Sommige systemen draaien op een standaard database (bijvoorbeeld MySQL of SQL Server) die je, met toestemming en de juiste kennis, rechtstreeks kunt uitlezen. Dit omzeilt de leverancier volledig: je leest de tabellen uit zonder tussenkomst van een export-functie of interface.

Dit klinkt aantrekkelijk omdat het snel en flexibel is, maar er zitten grote haken aan. Ten eerste is het vaak in strijd met de licentievoorwaarden van de software, zeker bij cloudpakketten waar je geen directe toegang tot de onderliggende database hoort te hebben. Ten tweede is de structuur van die database niet gedocumenteerd en niet stabiel: bij een update kan een tabelnaam of kolom veranderen zonder waarschuwing, en dan valt je koppeling zonder aanwijsbare reden stil.

Deze route is alleen te overwegen bij on-premise software waar je zelf (of via je IT-partij) beheerder van bent, met uitdrukkelijke toestemming van de leverancier. Bij cloudsoftware raad ik dit af: de kwetsbaarheid is te groot en de juridische risico's wegen niet op tegen het gemak.

Route 5: zelf een tussenlaag bouwen

De meest robuuste route als een leverancier geen koppelvlak biedt, is er zelf een omheen bouwen. Dat klinkt tegenstrijdig, maar in de praktijk betekent het dat je een kleine, eigen applicatie of workflow neerzet die de export, import of scraping netjes inpakt en naar buiten toe gedraagt als een echte koppeling.

Zo'n tussenlaag doet drie dingen die de losse routes hierboven niet vanzelf doen: het controleert of de data compleet en correct is voordat die wordt doorgezet, het logt fouten zodat je ze kunt opsporen voordat een klant of collega ze ontdekt, en het biedt jouw eigen systemen een stabiele interface, ook als de bron eronder verandert. Verandert de export van de leverancier, dan pas je alleen de tussenlaag aan, niet alle systemen die ervan afhankelijk zijn.

Dit is in essentie maatwerk software, al gaat het vaak om een compacte tool en niet om een groot systeem. De investering ligt hoger dan bij een simpele workflow, maar lager dan bij RPA op de lange termijn, omdat je iets bouwt dat bedoeld is om stabiel te draaien in plaats van een interface na te bootsen. Voor bedrijven die structureel tegen het ontbreken van een koppelvlak aanlopen, is dit vaak de verstandigste keuze: je koopt voorspelbaarheid terug. Op automatisering leg ik uit hoe zo'n aanpak past binnen een breder automatiseringstraject, en in zelf bouwen of uitbesteden ga ik dieper in op de afweging wie dit voor je bouwt.

Route 6: de leverancier onder druk zetten of vervangen

Voordat je zelf gaat bouwen, loont het om eerst te vragen. Leveranciers geven soms alsnog toegang tot een API als je aantoont dat je een betalende klant bent met een concrete zakelijke reden, vooral als er al een interne API bestaat die simpelweg niet openbaar wordt aangeboden of gedocumenteerd. Vraag expliciet naar een koppeling, een export-API of een partnerprogramma voor integraties. Dit kost niets behalve tijd, en soms levert het meteen de oplossing op die je zocht.

Werkt dat niet, dan is het moment aangebroken om te kijken of het pakket zelf nog wel bij je past. Een leverancier die structureel geen koppelvlak wil bieden, geeft daarmee een signaal af over hoe hij naar de toekomst van zijn product kijkt. Als je bedrijf groeit en steeds meer systemen met elkaar moet laten praten, is een gesloten pakket een steeds grotere rem. Overstappen is een ingrijpende stap, maar soms de enige die op lange termijn goedkoper is dan jaren pleisters plakken.

Kosten en kwetsbaarheid per route naast elkaar

Om de keuze concreet te maken, zet ik de zes routes hieronder naast elkaar op de twee dingen die er echt toe doen: wat het kost en waar het breekt.

• Handmatige export/import: geen directe kosten, hoogste kwetsbaarheid door menselijke fouten en uitval van personeel.
• Export op schema: beperkte bouwkosten, kwetsbaar voor stille wijzigingen in bestandsformaat, vertraging in actualiteit.
• Screen scraping/RPA: wisselende bouwkosten, structureel hoog onderhoud door gevoeligheid voor interfacewijzigingen.
• Directe database-toegang: lage bouwkosten maar juridisch risico en instabiele structuur, alleen bij on-premise met toestemming.
• Eigen tussenlaag: hogere eenmalige investering, laagste structurele kwetsbaarheid, beste optie bij herhaald gebruik.
• Leverancier vervangen: hoogste eenmalige kosten en overgangsrisico, maar enige route die het probleem definitief oplost.

Wat opvalt: de goedkoopste route op korte termijn (handmatig werk) is bijna altijd de duurste op lange termijn, omdat de kosten verschuiven naar fouten, tijd en gemiste kansen. Andersom geldt dat de duurdere routes (tussenlaag, overstap) vaak de enige zijn die het probleem echt wegnemen in plaats van uitstellen. Meer over de bredere afweging tussen kant-en-klaar en zelf koppelen lees je in standaardpakket of zelf koppelen.

Wanneer je beter kunt overstappen

Er is een duidelijk omslagpunt waarop pleisters plakken duurder wordt dan overstappen. Dat punt herken je aan een paar signalen die vaak samen optreden.

• Je koppelt meer dan twee systemen op elkaar en elke koppeling is een losse noodoplossing zonder gemeenschappelijke structuur.
• Je onderhoudt regelmatig kapotte koppelingen omdat de leverancier zonder aankondiging iets wijzigt aan export of interface.
• De data die je nodig hebt, is bedrijfskritisch: facturatie, voorraad, klantgegevens, waar een fout direct geld of vertrouwen kost.
• Je groeit, en het aantal keer per week dat je tegen de beperking aanloopt neemt toe in plaats van af.

Zie je twee of meer van deze signalen bij jezelf, dan is het verstandig om niet nog een noodoplossing te bouwen, maar te onderzoeken of een ander pakket, of een centrale dashboard-laag die meerdere bronnen samenvoegt, structureel goedkoper uitpakt. Een goed startpunt is een audit van je huidige systemen, waarin in kaart wordt gebracht welke koppelingen je nodig hebt en welke route daarbij past.

Hoe ik dit vraagstuk aanpak

Als een klant bij me komt met "mijn software heeft geen API, wat nu", begin ik nooit met de technische oplossing. Ik begin met de vraag hoe vaak het probleem zich voordoet, wat de data waard is als die niet klopt, en hoe lang het pakket nog meegaat in de plannen van het bedrijf. Die antwoorden bepalen of een simpele export op schema volstaat, of dat een eigen tussenlaag of zelfs een overstap logischer is.

Vaak blijkt dat een combinatie het beste werkt: op korte termijn een export op schema om vandaag verder te kunnen, en op langere termijn een tussenlaag of nieuw systeem als de groei dat rechtvaardigt. Dat voorkomt dat je vandaag een dure oplossing bouwt voor een probleem dat over een jaar toch verdwijnt, en voorkomt tegelijk dat je jarenlang handmatig werk blijft doen voor iets dat allang geautomatiseerd had kunnen zijn.

Op diensten lees je hoe ik dit soort trajecten opbouw, van een eerste export-oplossing tot een volwaardige koppeling of eigen tussenlaag. En op over lees je waarom ik dit als zelfstandige aanpak in plaats van als bureau met een vast sjabloon: elk pakket, elke leverancier en elke situatie vraagt om een andere afweging tussen snelheid, kosten en kwetsbaarheid.